...
- Dynamic Device Provisioning
- Support the dynamic onboarding of new devices which conform to an existing device profile
- This eliminates the need to itemize devices in the device service configuration.toml
- Also could include the dynamic re-assignment of a device from one device service to another as in the case of a moving (wearable) device
- Error Handling Refactoring
- https://github.com/edgexfoundry/edgex-go/issues/1734
- Anthony Bonafide presented a possible approach in Core WG (22-Aug-2019)
- Explicit Request and Response types for API endpoints
- These would be defined in go-mod-core-contracts
- The current models used for request/response as found in go-mod-core-contracts was extracted from edgex-go so that other applications would not have to import the entirety of edgex-go in order to be interoperable.
- There is unnecessary complexity involved when creating requests (see devices and device services) because of requirements applied to the model's integrity but not necessarily the request
- All requests and responses for the Core/Supporting service APIs should have explicit request and response models.
- Example: AddDeviceRequest, AddDeviceResponse, UpdateDeviceProfileRequest, UpdateDeviceProfileResponse
- If Geneva becomes V2, how to support V1?
- Proposal – Rather than keeping the /v1 code in the various repos that rev to /v2, we should branch the most recent v1.x release into an LTS branch.
- Subsequent supporting changes would be made there.
- This LTS branch will never have any /v2 code.
- The above removes all /v1 code from the /v2 codebase. Thus an application interacting with the /v2 codebase could not expect to call a /v1 endpoint and have it work.
- Proposal – Rather than keeping the /v1 code in the various repos that rev to /v2, we should branch the most recent v1.x release into an LTS branch.
- Elimination of Value Descriptors
- The current ask is to include the typing metadata on the event readings themselves.
- Querystring support in the Event payload
- The use case here is that certain device services require querystring parameters in order to obtain readings from one or more registers within a single device (such as Intel's RFID case)
- Inclusion of the querystring params was proposed as a way to record what the source register was when the event was created
- Just tracking it back to the device may not be granular enough
- Configuration.toml structural changes as warranted
- Specifics will be added per discussion
- Example – Align security service configuration structure to standardize with Core Services
- Core Services Monolithic deployment
- During the planning of Fuji there was discussion related to the possibility of deploying Core/Supporting services as a monolith. Some prototyping was done. Do we want to pick this up?
- Messaging directly between Southside / Northside
- Bypass core-data, etc
- Support some other messaging bus besides ZeroMQ
- Environment variable overrides in order to remove the docker configuration.toml
- Use base configuration.toml, override docker hosts and other relevant settings via environment vars in docker-compose.
- Applicable to docker deployments only