Hello Ashok Your final comment to Thiago about increasing the effort on application developers was a point I wanted to make based on my reading of Jinguk?s slides (slide 4).
I had always believed we were developing the APIs and so that application developers didn?t have to know about transports or physical layers. I believe that this goal should be top of mind when it comes to architecture and design decisions; so for that reason I feel the PPM approach is preferred. Regards, Bernie From: ASHOKBABU CHANNA <ashok.channa at samsung.com<mailto:[email protected]>> Reply-To: "ashok.channa at samsung.com<mailto:ashok.channa at samsung.com>" <ashok.channa at samsung.com<mailto:ashok.channa at samsung.com>> Date: Thursday, March 19, 2015 at 7:38 PM To: "Macieira, Thiago" <thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>>, "iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>" <iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>> Subject: Re: [dev] About ZigBee, Z-Wave Supporting Hi, Even though PPM approach is default approach to be considered, Encapsulation (2nd approach) provides additional benefits such as 1) Used by all OIC devices (Rich/Light) . 2) Make unified approach for OIC devices like BT/BLE connectivity?s. 3) New use-cases such as handling Zigbee devices at single hop or multi hop with OIC framework. For ex:: If we have 3 devices - A ( OIC Device- BLE) , B ( OIC Device - BLE/Zigbee) , C ( Zigbee device). From A-B , it can be a OIC protocol(payload zigbee command) and from B to C its Zigbee interaction using OIC framework itself. And benefits will come with a cost.. it makes applicationput more effort. But this is valid scenario as application have more idea of Zigbee Profile . In my opinion, encapsulation is also good approach to be considered for better OIC device expansion. Regards, Ashok ------- Original Message ------- Sender : Thiago Macieira<thiago.macieira at intel.com<mailto:thiago.macieira at intel.com>> Date : Mar 19, 2015 23:13 (GMT+09:00) Title : Re: [dev] About ZigBee, Z-Wave Supporting On Thursday 19 March 2015 06:21:56 JinGuk Jeong wrote: > Dear IoTivity Developers, > > Since I want to technically discuss about a way how to support > ZigBee/Z-Wave, I am sending an email to you. I think this feature is very > important feature because there are so many ZigBee/Z-Wave devices in the > world. However, we need to consider several issues such as chip dependency, > code size, and so on. Currently, there are two approaches for that, and you > can find these approaches in attached file. Plz give your feedback about > this. Hi Jinguk Thanks for sharing the outlines of the two options. I'm probably missing something... it seems quite straightforward to me that the simplest answer would be #1, which is why I think I am missing something. Why would option #2 be considered? My thinking is: 1) the Zigbee/ZWave wire protocol and message format is wildly different from the OIC one (discovery, communication, authentication, encryption, authorisation, etc.). That means the only abstraction that would be common between OIC and a Zigbee device is at the level of a service. That is, a lightbulb is still a lightbulb by any other name. 2) there are probably existing libraries to talk to zigbee adapters and speak zigbee protocols (or zwave), which means we would spend less time trying to abstract them on CA. Instead, we gain time by simply wrapping them at the highest level possible -- the service layer. The only thing that comes to mind about wanting to have CA service zigbee is if we wanted to share the infrastructure between multiple zigbee-capable devices. But isn't that what the zigbee libraries should already be doing? Do such iibraries exist? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev [cid:93BIV0UVOUUB at namo.co.kr] -------------- next part -------------- A non-text attachment was scrubbed... Name: 201503201138460_QZUWXYH6.gif Type: image/gif Size: 13168 bytes Desc: 201503201138460_QZUWXYH6.gif URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150320/58f20122/attachment.gif>
