Wow, interesting discussion erupts! It's worth remembering that iotivity is different things to different people. As "an implementation of OCF specifications" one would tend to a more conservative view of what goes into the codebase. But it is also used as a foundation to develop features that their developers need for their own plans. Some of those may make their way into the OCF specs (sometimes it's a matter of timing), some will be modified before going in, some may not make it in. Now if you want to discuss how this works here vs other open source projects, that would be an interesting discussion. iotivity as a whole could probably stand to have a fresh discussion of whether those extra things are part of a "release" or not - I guess OSWG probably has had some of this discussion in the context of the QA activities.
I believe the perspective is also very different depending on whether you look at it through the lens of the device maker (which has been the primary motivator of iotivity development so far) or of the app developer. If I think as an app developer, I'm surprised at how much there is to the API given how essentially simple the protocol is. But to the device maker, if the stack does what it's supposed to do - responding to stuff coming in on the wire and reacting appropriately - there's not much of a problem, because I'm not really doing much directly with the API. _______________________________________________ iotivity-dev mailing list [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
