Hi Thiago, Regarding the Primitive service Protocol Plugin Manager, You seems to have different expectation from current implementation. OIC Resource point of view, PPM does not provide additional functionality yet. PPM does not have any mechanism related with this feature that is PPM ?framework will map the different property names and values back onto a standardized and richer API? Resource Request Handling is up to the Protocol plugin developer?s role.
However, PPM provides help the lifecycle management of that Resource Server, more specifically, how to invoke That resource server. Furthermore, we can design the AllSeen generic Protocol plugin which enable property and value mapping for each specific resource type might be done thru configuration file setting. Summarizing my opinion : From the view of resource handling thru the standardized and supportable API, Option 2, 3 same. However, Option3 will provide the lifecycle management of that resource. BR, Uze Choi From: [email protected] [mailto:iotivity-dev- bounces at lists.iotivity.org] On Behalf Of ??? Sent: Thursday, March 26, 2015 9:03 AM To: iotivity-dev at lists.iotivity.org Subject: Re: [dev] Plugins for non-OIC devices Thiago, Thanks for below opinion. Currently, connectivity abstraction have been maintained by pat (maintainer of discovery & connectivity project). Uze (maintainer of primitive service project) have maintained Protocol Plugin Manager and Plugins. So, I am wondering about his opinion, too. Uze, could you share your opinion about that? I think a bond of sympathy can developed, even though there are some different opinions among us. I will decide after discussing with maintainers and architects if there will be a wide divergence of opinion. (firstly, ZigBee & Z-Wave Issue) Before then, I am going to finally check whether there are different opinions or not in a few days. BR Jinguk Jeong ------- Original Message ------- Sender : Thiago Macieira<thiago.macieira at intel.com> Date : 2015-03-26 03:13 (GMT+09:00) Title : [dev] Plugins for non-OIC devices 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 _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Jinguk Jeong, Software R&D Center, SAMSUNG ELECTRONICS CO., LTD Email : jinguk.jeong at samsung.com 010-3244-4110 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ <http://ext.samsung.net/mailcheck/SeenTimeChecker?do=a89e2f31c590267a8dd0003 77cfe0c3b784df2f6d93f59efc02ed1e8db42db2113d69ea60670f66e1fac5bf6c61543587bc 8a6096cfbfc9f02e038c8d853bffbdb9fdddda33e82cbe4a391424e62fcf6cf878f9a26ce15a 0> -------------- next part -------------- HTML ?????? ??????????????... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150326/fb22f6a3/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13168 bytes Desc: ?????? ?? ????????. URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150326/fb22f6a3/attachment.gif>
