...
Name | Company |
---|---|
Orange | |
Ericsson | |
DT | |
VDF | |
VDF | |
Doug Hutchinson | Vonage |
Telefonica | |
Telefonica |
...
# | Company | Summary | ||||
---|---|---|---|---|---|---|
Ericsson | Area Data-type | |||||
Telefonica | New release scope | |||||
Telefonica | Align with guidelines for async responses | |||||
Ericsson | Support time Windows in the past | Orange | Make the API more developer friendly | |||
Orange | Change maxPplDensity, minPplDensity and pplDensity datatype | |||||
Telefonica | Include notification ID for callback | |||||
Telefonica | Include new error status for callback | Telefonica | Simplify APIOrange | Align API with commonalities errors | ||
Ericsson | Include past results in API | |||||
Telefonica | Include Operation ID |
Approval of previous meeting minutes & documentation (1)
→ Approved
API proposal review (2)
...
Status: Commonalities closed for circle and polygon, enough for PDD.
AP: Check if format in commonalities is aligned with current PDD and align if neededTo align, TEF
Propose new scope for next release.
...
AP: include use cases in the API scope (readme) and yaml/testplan to ensure API is also aligned
Status:
PR#60
Easing code parameters and polymorphic formats
Status:
The polymorphic patter use on line 576-578 is not developer-friendly as it require a manual processing with code generator. It will be better to use same name for the enum value and the corresponding class.
→ Just align naming in classes and enum, maintaining polymorphic
There is probably unnecessary complexity with all the classes defined in the yaml. We can merge
CellPopulationDensityData
andPopulationDensityData
in one class and avoid one unnecessary level that will make the API sipler→ Check if this change breaks or not the polymorphic
Proposal to maintain at level of cellPopulationDensityData, merge PopulationDensityData in one big class including both curren geohash and the rest of parameters now included inside cellPopulationDensityData:
"cellPopulationDensityData": [
{
"geohash": "u09tsm9",
"dataType": "DENSITY_ESTIMATION",
"maxPplDensity": 25737.0,
"minPplDensity": 12704.0,
"pplDensity": 24273.0
}
The class
DensityEstimationPopulationDensityData
has probably too many Density but this point is linked to my first point.→ solved by point 1
Value format (double/integer) for density data
Status: move to integer format
Include ID in notification to track request-response
Status: create PR with this new parameter, aligned with QoD sessionID mechanism
Include error status for callback response if area cannot be processed
...
AP: check with geofencing, also around the 400/422 in the sync mechanism
Solving 56 & 58Issue#67
Align error with commonalities 0.5
Status:to be merged by the end of the day
AP: Orange to include PR
Solving 51
Status: to be reviewed and merged, leaving historical age restriction open for the moment
Solving 61
Status: to be merged, as soon as conflicts are resolved
AoB (4)
Next steps:
Close current PRs to freeze API content
Align commonalities as expected
Release tracker created for 0.2.0, RC to be created before 15/01 (next meeting)
...
# | Summary | Status/conclusion | |||
---|---|---|---|---|---|
Area Data-type | Align wth commonalities, if changes are requiredTelefonica to include PR | ||||
New Release Scope | ALL to provide more proposals | ||||
Aling with guidelines for async responses | |||||
Support time Windows in the past | Review and merge PR60 | Easing code parameters and polymorphic formats | Review and merge PR59 | ||
Value format (double/integer) for density data | Review and merge PR59 | ||||
Include ID in notification to track request-response | Align with QoD sessionID and create PR | Include error status for callback response if area cannot be processed | Align error with geofencing (if applies) and align 422/400 error as wellPR to be merged | ||
Align API with commonalities errors | Orange to include PR |
Next steps
Scope for next release → #17
...