Skip to content
This repository has been archived by the owner on Oct 12, 2023. It is now read-only.

Azure IoT Gateway SDK

Compare
Choose a tag to compare
@andrew-buckley andrew-buckley released this 19 Nov 02:06
· 379 commits to master since this release
783b96f

This is the first official release for the Azure IoT Gateway SDK.

Breaking Changes

JSON gateway definition

  • Added a "loaders" array, to customize how modules are loaded into the gateway. (See new features)
  • Restructured the "modules" object, "loading args" is replaced by a "loader" object, which names the module loader to use and the entrypoint for the module.
  • Renamed fields:
Old New
module name name
module path module.path
main path main.path
dotnet_module_path assembly.name
dotnet_module_entry entry.type
class_path class.path
library_path library.path
jvm_options jvm.options
debug_port debug.port
additional_options additional.options

Public API Changes

  • Module_CreateFromJson was removed from the module api version 1 and replaced with Module_ParseConfigurationFromJson and Module_FreeConfiguration. The module api remains at version 1.
  • Module_GetApi is defined as expecting MODULE_API_VERSION gateway_api_version - removed const.
  • dynamic_loader.h was moved to module_loaders/dynamic_loader.h, and this has been extended to become the "native" module loader.
  • In GATEWAY_MODULES_ENTRY, loader_configuration and loader_api fields were removed and replaced by module_loader_info.

New Features

  • Enhancements to how an architect can configure module loading.
    The Gateway now supports 4 module loader types: native, java, Node.js and C#, and there is one default loader for each type. These default loaders may be used as is, modified to suit the gateway architect's needs, or duplicated with a new name and altered.
    The new "loaders" array of the JSON configuration is used to modify or create new module loaders. The "loaders" array may be omitted if the user only references the unmodified default loaders.
    New modules loaders may be written in C by conforming to the MODULE_LOADER_API.
  • The new module loaders allow Java, Node.js and C# developers to avoid knowing the details of how the language binding ties into the gateway.
  • Users do not need to install or build SDK dependencies that are already installed.
    Users may install the IoT SDK devices library manually or through the IoT Gateway build process. If the libraries are found, the gateway will use those libraries, Otherwise, the libraries are built once and installed. This reduces disk space and build time for each developer.
  • MODULE_API changes. Module_CreateFromJson was removed from the module api version 1 and replaced with Module_ParseConfigurationFromJson and Module_FreeConfiguration.
    This separates the JSON parsing functionality from the module creation functionality. Module_ParseConfigurationFromJson is expected to produce the data needed for Module_Create, and Module_FreeConfiguration is expected to free any resources created by Module_ParseConfigurationFromJson.

Doc Updates

Significant documentation updates occurred during this release, as a result of the module loaders feature. Some other structural changes are:

  • Added featured modules in top-level README.
  • introductory tutorials were moved into the appropriate sample README.
  • All references to Beta have been removed from documentation.

Changes/Bug Fixes

  • Allow Linux developers to exclude the BLE module from the build
  • Java binding is tested in x64 windows build.
  • When building Node modules and sample, copy node.dll to the output folder
  • Default class path for java modules is located in /usr/local/lib/azure_iot_gateway_sdk-1.0.0/bindings/java/classes in Linux and either the %PROGRAMFILES%\azure_iot_gateway_sdk-1.0.0\lib\bindings\java\classes or %PROGRAMFILES(X86)%\azure_iot_gateway_sdk-1.0.0\lib\bindings\java\classes for Windows (64 and 32 bit systems, respectively).
  • Print the module's path when it fails to load.
  • Fix BLE write instruction access violation.
  • Moved a few more event-system specific structures into "experimental"