NOTICE: This code is currently on IoTivity master. This code will be found in IoTivity 1.3 and beyond.
As IoTivity is compliant with only the OCF ecosystem (with relatively low to no native devices on the market) the community needs a way to bridge into other ecosystems to leverage ongoing support for the ever-growing OCF ecosystem. It is beneficial for developers and product manufacturers to support the OCF ecosystem as early as possible. The Bridging Project aims to provide the infrastructure and plugins to support developers and product manufacturers. Since IoTivity is open source, any developer or product manufacturers can help create more plugins.
Some OCF & IoTivity members have developed the infrastructure and plugins needed to spur the Bridging Project. For now, some of the material is still undergoing review by the IoTivity community under the IoTivity-dev mailing list.
Every bridging implementation is referred to as a “plugin.” The infrastructure these plugins fit into is referred to as “Mini Plugin Manager.”
IoTivity's Bridging Project consists of three core components:
Considerations: There are three bridging schemes within OCF & IoTivity. Two are certifiable now with the OIC1.1 specification while the other will be certifiable in the future with the OCF1.0 specification.
The first scheme you can choose to proxy for an OIC Smart Home device type directly. This scheme works with OIC1.1.
In this scheme you have a single instance of IoTivity per device type and proxy any discovery, create, retrieve, update, delete, or notify requests between the client and bridged device.
The second scheme you can choose to implement is to map between ecosystems. This scheme works with OIC1.1.
This scheme is much like the first one, except you can host more than one OIC Smart Home device type in a single instance of IoTivity. You set the device type of your instance of IoTivity to "oic.d.bridge". Then you represent each device you want to host as a collection resource. Each collection that you create that has a device type (i.e. "oic.d.*") in the array of resource types is recognized as a device. Each collection recognized as a device binds the associated resources within it. (Use "bindResource" API for this.)
The third scheme you can choose to implement in to bridge ecosystem-to-ecosystem. This scheme will work with OCF1.0.
This scheme is under implementation in its own project: https://gerrit.iotivity.org/gerrit/#/admin/projects/iotivity-alljoyn-bridge Please refer to that project for current status.
Current supported plugins:
Plugin Implementations can be found here: <iotivity>/bridging/plugins/
The Mini Plugin Manager (MPM) is the infrastructure component of the Bridging Project. This is implemented as a C/C++ Library. Since this piece is implemented as a library, a sample application “MPM Client” has been developed to flex the usage of the APIs.
The MPM is poised with the following functionality:
The Mini Plugin Manager header and source files can be found here: <iotivity>/bridging/minipluginmanager
Since the Mini Plugin Manager is implemented as a library, it required a head (or application-level invocation). The MPM Client was created to fulfill this need. The MPM Client simply wraps the Mini Plugin Manager and offers a command line interface to flex the APIs.
Note: You may invoke the Mini Plugin Manager APIs directly without the MPM Client.
The MPM Client header and source files can be found here: <iotivity>/bridging/mpmclient
Metatags: bridge project, mini plugin manager, mpm, minipluginmanager, plugin, mpmclient mpm_client, mini_plugin_manager, miniplugin, mini_plugin, pluginmanager, plugin_manager