...
- Improved Security
- Interoperability testing
- Dynamic device provisioning/on-boarding
- Alternate messaging support (to 0MQ)
- Archive of Export Services - in favor of Application Services which was implemented with the Edinburgh and Fuji releases
- DevOps will move CI/CD to Jenkins Pipelines
- Request/response changes and API redefinition
- User guidance on platform needs
- More performance statistics
- # of devices/per recommendations
- Providing EdgeX users guidance on platform needs, sensor data throughput and deployment based on performance metrics. Specifically, with the Geneva performance testing apparatus, the EdgeX community will be able to answer these questions for the user:
- 1) Will EdgeX fit on my system? - size of EdgeX services, infrastructure, etc. and hardware/platform requirements
- 2) What is the speed of data through the system? - from device service sensor data ingestion to the rules engine and back down through command to another device service to trigger a put command, how long does this take?
- 3) How many “things” can be processed at a time? – with caveats on the type of thing, type of data, etc.
- These questions need to be answered on real hardware (both Intel and ARM)
- Dynamic device provisioning/on-boarding
- Alternate messaging support (to 0MQ)
- Archive of Export Services - in favor of Application Services which was implemented with the Edinburgh and Fuji releases
- DevOps Jenkins Pipelines
- The first steps toward a revamped V2 API that includes cleaner (and fewer) endpoints and a simplified request/response model
- Provide an alternate local analytics service (archiving the Java-based rules engine service)