Delivery:  ~ April 2019

The Edinburgh release will likely focus on the implementation of a certification program, footprint improvements (replace MongoDB), export service replacement (application services) & system RAS (reliability, availability, and scalability) in addition to additional security and system management needs that were started in 2018.

Release Themes and Objectives

• Define and implement a certification program for microservice drop in replacements
  This will allow 3rd parties to add value (proprietary or open source) to EdgeX that customers can rely on to meet the EdgeX APIs and work without additional code change.
• Replace existing export services with application services.
  The application services will provide a more modular/SDK-generated approach to northbound services that scale better and will tailored to the use case.  In the export distribution service (Java or Go), facilities to provide endpoints with EdgeX data are statically programmed into the pipeline of this service today.  That is, when data comes to export distribution, based on a client’s registration, it is filtered, transformed/formatted, compressed, and then encrypted.  Some options are provided (like allowing formatting in JSON versus XML), but these options are again statically built into the export distribution pipe.  If a user wishes to add new filters, new transformations (example adding a CSV format), new encryption or compression routines, then the user must get the export-distro code base, fork it and make their own copy.  Is there a way to create plugins or modules into the pipe-filter architecture of the export-distro so that it is more flexible to meet new needs going forward?  Is it possible to make some sort of SDK for the export-distro service so users can essentially create a custom export facility with the options for filtering, transforming, enriching, etc. the EdgeX data as they see fit without having to fork and rebuild the entire micro service on their own?  Allow the export services to look and feel more like the device services in addressing specific north end connectors (see here for preliminary ideas).
• Provide a MongoDB alternate for sensor data and EdgeX data persistence
• Offer additional security and system management functionality that was begin in 2018.
• Provide a full complement of reference implementation device services created with the Go and C SDKs (that were provided with the Delhi release).  This will likely include device services for Modbus, BACNet, BLE, MQTT, SNMP and more.
• Support ARM 32 deployments