Thx! Some thoughts: For IOTIvity-Lite the next consideration should be important:
- (static) Code size - Memory/Run size Being currently the smallest OCF code base, it should be ensured that the code/run size does not get inflated. Hence it should have the minimal API to create all functionality that is in the OCF specs. 1 mechanism (API) only, having more than 1 method Increases code size and requires more testing. I guess this should be in a wiki for IOTivity-Lite Hope this helps, Wouter From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Christian Gran Sent: 06 April 2018 07:50 To: Mats Wichmann <m.wichm...@ieee.org>; iotivity-dev@lists.iotivity.org Subject: Re: [dev] API proposal for better userability in IoTivity Lite. Hi, thanks for the links - that is helpful. Disucssing a ‘feature’ on the mailing list is a good first step. What we do not have in place is a mechanism to accpet or reject a feature request - or did I miss that part? Thoughts? thanks Christian On 5. Apr 2018, at 17:01, Mats Wichmann <m.wichm...@ieee.org<mailto:m.wichm...@ieee.org>> wrote: To respond to this question: there is a documented process, which is here: https://wiki.iotivity.org/iotivity_features_branches_and_release_process now whether that process is actually followed in general is another question, but bringing the question here was supposed to be the first step, and that is what has happened. there's not a whole lot on the wiki on this project, beyond the one page: https://wiki.iotivity.org/constrained?s[]=constrained<https://wiki.iotivity.org/constrained?s%5b%5d=constrained> which could use some beefing up, reflection of the new name, etc. On Thu, Apr 5, 2018 at 12:34 AM, Christian Gran <g...@lynxtechnology.com<mailto:g...@lynxtechnology.com>> wrote: Hi, do we have a process in place where we agree on ‘requirements’ ? Why is multi threading a requirement - where does this come from? So far only reuqirements I have seen in Prag is OCF compliance and as small as possible, so that the stack fits in as many devices as possible. These are strong requirements that we have received by OCF and which we should always keep in mind. …and stack size is the major part why we now have so many companies looking at IoTivity Light! thanks Christian On 4. Apr 2018, at 21:02, Gregg Reynolds <d...@mobileink.com<mailto:d...@mobileink.com>> wrote: On Wed, Apr 4, 2018, 1:19 PM Gregg Reynolds <d...@mobileink.com<mailto:d...@mobileink.com>> wrote: On Wed, Apr 4, 2018, 3:53 AM 최우제 (Uze Choi) <uzc...@samsung.com<mailto:uzc...@samsung.com>> wrote: Hi Christian, Even though this is not needed by all developer, this is also required. Required by whom? To satisfy this requirement, minimal code needs to be added. I don’t think it take lots of code. It would set a bad precedent. Pretty soon other vendors would want to do the same thing for their particular needs. What's wrong with creating a library to support this "requirement"? I'll add that moving a vendor-specific solution into the kernel kills a competitive space. You want MT? Acme Corp. has a solution; so does Bravo Corp. They're optimized differently. Let the market decide which is better. Move Acme's solution into the official release and you kill that market. Please do not follow the path of Iotivity. Simple example : the Java API. That should never have been a part of core iotivity. I've got a completely different Java API in the works. A great many such apis are possible. Coronating just one as the official API is not so helpful, imho. Gregg _______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
_______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
