Sorry for late response due to mail system filtering. I didn’t ware of it.
I think open source project need to have two most important quality factors
which are extensibility for more usage and maintainability.
Of course some project could be the optimization is most important.
It looks important that we keep the good balance considering various factors.
I think no one change for other request is not way to move on where open source
If my change proposal is against current concept or big shift from current
architecture, I get it. But this is not.
BR, Uze Choi
From: Wouter van der Beek (wovander) [mailto:wovan...@cisco.com]
Sent: Thursday, April 05, 2018 6:53 PM
To: Christian Gran; Gregg Reynolds; 최우제(Uze Choi); Maloor, Kishen;
Subject: RE: [dev] API proposal for better userability in IoTivity Lite.
Just a thought.
We can have different code generators on top of the API.
The differences are then in the generated code (application layers).
One template can be with mutexes on all the callbacks since the code will be
used in an threaded environment.
Other template can be without mutexes, since the code will run in an single
This approach also keeps the API/code to a minimum set to pass CTT validation.
The only resources that needs to be in the stack itself are the mandatory
resources that make up the device/client.
All other resources should be in the application layer and the APIs should be
sufficient of level to create all wanted resources.
Hope this helps,
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Christian Gran
Sent: 05 April 2018 07:35
To: Gregg Reynolds <d...@mobileink.com>; 최우제(Uze Choi) <uzc...@samsung.com>;
Maloor, Kishen <kishen.mal...@intel.com>; email@example.com
Subject: Re: [dev] API proposal for better userability in IoTivity Lite.
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
On 4. Apr 2018, at 21:02, Gregg Reynolds <d...@mobileink.com> wrote:
On Wed, Apr 4, 2018, 1:19 PM Gregg Reynolds <d...@mobileink.com> wrote:
On Wed, Apr 4, 2018, 3:53 AM 최우제 (Uze Choi) <uzc...@samsung.com> wrote:
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.
iotivity-dev mailing list