Greg, You were on the right track by calling out the W3C because their web-of-things architecture is addressing the issues that you raised, and there’s already an iotivity integration for it, however it appears to be inactive. I think you’ll find these links quite useful/informative. https://w3c.github.io/wot-architecture/#sec-building-blocks https://w3c.github.io/wot-architecture/#sec-servient-architecture https://w3c.github.io/wot-scripting-api/ https://www.theinternetofthings.eu/michael-koster-i-am-building-wot-servient-based-iotivity-ocf-open-connectivity-foiundation-resource
From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Gregg Reynolds Sent: Friday, May 4, 2018 4:18 PM To: Thiago Macieira <thiago.macie...@intel.com> Cc: iotivity-dev <iotivity-dev@lists.iotivity.org> Subject: Re: [dev] Android Thingies Thanks. Comments below. On Fri, May 4, 2018, 2:25 PM Thiago Macieira <thiago.macie...@intel.com<mailto:thiago.macie...@intel.com>> wrote: ... I've been hearing about Android Things and its predecessor project (Brillo) for two or three years now and they have little to show for it. In the last incarnation whose details I saw, it was a shrunken down Android, meant to run on devices with about 256-512 MB of RAM, as it still tries to run the JVM to provide API. It's basically Android minus graphics. Plus some libraries to expose IoT stuff like talking to sensors. IOW, an OS plus a bunch of libraries? The big feature is that they'd be centrally managed by Google, so once you onboard your device, it shows up on your dashboard somewhere on google.com<http://google.com> and Google would manage the necessary updates for security. I wonder what that would mean for iotivity OTA updates. Maybe nothing. Any Android build of an OCF application should run on it and so could native applications built using an NDK. So in that sense, Android Things and OCF are not competitors, but complement each other. Why did Google not provide an OCF API? Maybe because there is no API? I've been thinking that it might be a Good Thing for us to define an abstract API, just like W3C did for the DOM. OCF is a protocol, no API there, but a standardized API might encourage adoption. Bonus question: is there always (or ever) an optimal API for a protocol? There are infinitely many ways to implement protocol support, but APIs are a 'nother matter. IOW, an OCF client must accept responses, and the format of those responses is well-defined by the spec (I think). It follows that we can define an API for accessing those responses. You don't have to use those APIs in order to be OCF-compliant, but if you do, life is easier for consumers, and also for devs who want to add language bindings. Not to mention implementors who want to support the standard API but compete on e.g. parformance. (I'm not entirely sure this makes sense, since it is Friday afternoon happy hour, after all.) Gregg
_______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
