Thanks. Comments below. On Fri, May 4, 2018, 2:25 PM Thiago Macieira <[email protected]> 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 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 [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
