Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-02 Thread Maloor, Kishen
Hi Uze, As the framework is single-threaded by design, many internal modules operate on global structures. So, the global CborEncoder objects used in oc_rep aren’t an exception, and are in fact an efficiency that takes advantage of the single-threaded design. Consequently, just modifying oc_rep to

Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-02 Thread Uze Choi
r to exsiting IoTivity API concept, I think. We can make it enabled with patch into tiny_cbor. BR, Uze Choi From: Maloor, Kishen [mailto:kishen.mal...@intel.com] Sent: Tuesday, April 03, 2018 12:47 PM To: 최우제 (Uze Choi); iotivity-dev@lists.iotivity.org Subject: Re: [dev] API proposal for be

Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-02 Thread Christian Gran
l 03, 2018 12:47 PM To: 최우제 (Uze Choi); iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org> Subject: Re: [dev] API proposal for better userability in IoTivity Lite. Hi Uze, As the framework is single-threaded by design, many internal modules operate on global structures

Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-03 Thread Thiago Macieira
On segunda-feira, 2 de abril de 2018 20:47:26 PDT Maloor, Kishen wrote: > Consequently, just modifying oc_rep to allocate them dynamically > wouldn’t make the APIs thread-safe. You shouldn't allocate TinyCBOR objects dynamically. The line that Uze proposed: CborEncoder new_rep = oc_rep_create_

Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-03 Thread Maloor, Kishen
y, April 2, 2018 at 10:17 PM To: Kishen Maloor mailto:kishen.mal...@intel.com>>, "iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org>" mailto:iotivity-dev@lists.iotivity.org>> Subject: RE: [dev] API proposal for better userability in IoTivity Lite.

Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-04 Thread Uze Choi
d build up. Send response to be done. For this scenario, separation of do_post_init and representation build need to be separated. representation build need to be done separate thread. BR, Uze Choi From: Maloor, Kishen [mailto:kishen.mal...@intel.com] Sent: Wednesday, April 04, 2018 8:16 AM To: 최우

Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-04 Thread Christian Gran
presentation build need to be separated. representation build need to be done separate thread. BR, Uze Choi From: Maloor, Kishen [mailto:kishen.mal...@intel.com] Sent: Wednesday, April 04, 2018 8:16 AM To: 최우제 (Uze Choi); iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org>

Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-04 Thread 박찬열
ice Lab(SR)/삼성전자 Date : 2018-04-04 17:16 (GMT+9) Title : Re: [dev] API proposal for better userability in IoTivity Lite.   Hi Kishen, Thank you feedback.   Let me clarify fundamental concern. I intend to “Remove the synchronization effort from the developer.” Samsung have developed sever

Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-04 Thread Uze Choi
...@lynxtechnology.com] Sent: Wednesday, April 04, 2018 5:22 PM To: 최우제 (Uze Choi); Maloor, Kishen; iotivity-dev@lists.iotivity.org Subject: Re: [dev] API proposal for better userability in IoTivity Lite. Hi, in my view a thread safe API is not needed by all developers. Therefore it should not be part

Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-04 Thread Uze Choi
r/Best Reviewer/Data Service Lab(SR)/삼성전자 Date : 2018-04-04 17:16 (GMT+9) Title : Re: [dev] API proposal for better userability in IoTivity Lite. Hi Kishen, Thank you feedback. Let me clarify fundamental concern. I intend to “Remove the synchronization effort from the developer.” Samsung ha

Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-04 Thread Gregg Reynolds
On Tue, Apr 3, 2018, 1:47 AM Christian Gran wrote: > Hi, > > in my opinion we should only add APIs if really really needed for > functionality. > IOTivity Light is about beeing small - if the functionality is available > or can be solved by the application already, no additional APIs are needed.

Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-04 Thread Gregg Reynolds
On Wed, Apr 4, 2018, 3:53 AM 최우제 (Uze Choi) 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

Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-04 Thread Gregg Reynolds
On Wed, Apr 4, 2018, 1:19 PM Gregg Reynolds wrote: > > > On Wed, Apr 4, 2018, 3:53 AM 최우제 (Uze Choi) 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. >>

Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-04 Thread Christian Gran
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

Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-05 Thread Wouter van der Beek (wovander)
) ; Maloor, Kishen ; iotivity-dev@lists.iotivity.org Subject: Re: [dev] API proposal for better userability in IoTivity Lite. 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

Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-05 Thread Mats Wichmann
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 t

Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-05 Thread Christian Gran
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 ma

Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-06 Thread Uze Choi
: 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; iotivity-dev@lists.iotivity.org Subject: RE: [dev] API proposal for better userability in IoTivity Lite. Just a thought. We can

Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-06 Thread Wouter van der Beek (wovander)
...@lists.iotivity.org] On Behalf Of Christian Gran Sent: 06 April 2018 07:50 To: Mats Wichmann ; 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

Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-06 Thread Gregg Reynolds
On Fri, Apr 6, 2018, 3:01 AM 최우제 (Uze Choi) wrote: > 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 proj

Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-07 Thread Gregg Reynolds
On Fri, Apr 6, 2018, 2:36 PM Gregg Reynolds wrote: > > > On Fri, Apr 6, 2018, 3:01 AM 최우제 (Uze Choi) wrote: > >> 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 extensi

Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-14 Thread Gregg Reynolds
On Fri, Apr 6, 2018, 3:01 AM 최우제 (Uze Choi) wrote: > 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 proj

Re: [dev] API proposal for better userability in IoTivity Lite.

2018-04-15 Thread Uze Choi
Hi Gregg, This is good strategy to make it work on a separate build system excluding it. BR, Uze Choi From: Gregg Reynolds [mailto:d...@mobileink.com] Sent: Sunday, April 15, 2018 4:34 AM To: 최우제(Uze Choi) Cc: iotivity-dev Subject: Re: [dev] API proposal for better userability in IoTivity Lite