Hello

Vijay, Sashi, Sundarshan, Sam and I were talking yesterday about connectivity 
abstraction and the protocol plugin support. I think we divided the problem in 
three groups:

1) transporting OIC over other radios (such as Zigbee/Z-wave)

In this case, we are not trying to interoperate with existing devices. We're 
merely using their radio to transmit our protocol payloads.

This would be implemented as a backend of Connectivity Abstraction (of the 
Transport Abstraction part of CA).

2) using the IoTivity resource manager to talk to non-OIC devices

In this case, we are trying to interoperate with existing, non-OIC devices. We 
are using their radios and/or their payload formats. A good example here is 
interoperation with AllSeen devices: both OIC and AllSeen use IPv4/IPv6, but 
the payload and protocol are totally different.

This would be implemented as a plugin to the resource manager but would not 
use the Connectivity Abstraction at all. The easiest way to implement AllSeen 
support, for example, would be to use AllJoyn, whcih has their own 
abstractions.

This rests on the assumption that the other protocol's model can be mapped to 
IoTivity's REST-style API.

3) using IoTivity primitive service to talk to non-OIC devices

The difference between #2 and #3 is how the remote device is exposed.

With just resource manager, any non-OIC device will be exposed as "generic, 
vendor-specific device". In other words, if someone is using only the Resource 
Manager (not Primitive Service) to control OIC, ZigBee and AllSeen light-
bulbs, they will have to write three different implementations because property 
names will be different. What we call "state" someone else may call "enabled"; 
what we call "brightness" someone may call "dimness" and invert the value.

On the other hand, if we implement Primitive Service support, then the 
framework will map the different property names and values back onto a 
standardised and richer API.

Is this accurate?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

Reply via email to