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. So if you can work around the threading in the app or by a higher layer - I would opt against adding things to IOTivity Light. It should not become a full purpose shop shop where everyone adds the same functionality multiple times blowing up the stack. Keeping it small is the major goal here. My suggestion: move out multi threading to a higher (optinal) layer - it is not needed by everyone.
my2cents Christian On 3. Apr 2018, at 07:17, 최우제 (Uze Choi) <uzc...@samsung.com<mailto:uzc...@samsung.com>> wrote: Hi Kishen, I appreciate your comment and effort in advance. However, my proposal is not to change the current concept. Please understand this. On top of current working concept, I just want to add additional API to work as local variable concept for oc_rep. This will give more flexibility if developer need and want. Otherwise, no change without this API usage. Regardless of how we can make upper layer working as multi thread concept, oc_rep is required to be made individually. Without this implementation on beneath layer, how genius upper layer logic could be built, multi thread access is not possible. Any my API change proposal give the consistence for oc_do_get and oc_do_post. This API is independent from thread locking. Just separation of concept, to separate the oc_rep making and do_post logic. Furthermore, this API add do not harm existing API concept also. Furthermore, current oc_rep_start_root_object() API is error prone with the responsibility for oc_rep_end_object(). However, if oc_rep_create…() API create the end ‘]’ brace. And we can add the key & value set in the middle. this will help for better understanding. This is similar 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<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. 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 allocate them dynamically wouldn’t make the APIs thread-safe. However, (equivalent) thread-safe APIs (with the same signature) can be implemented (wherever they’re necessary) in a thin upper layer, as an accessory, to be used by multi-threaded applications that don’t want to bother with locking themselves. I imagine this’ll be particularly useful in clients and to a limited extent in servers. I am experimenting with such a scheme and should post it once its done. Thanks, -Kishen. - Kishen Maloor Intel Open Source Technology Center From: <iotivity-dev-boun...@lists.iotivity.org<mailto:iotivity-dev-boun...@lists.iotivity.org>> on behalf of "최우제 (Uze Choi)" <uzc...@samsung.com<mailto:uzc...@samsung.com>> Date: Monday, April 2, 2018 at 1:58 AM To: "iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org>" <iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org>> Subject: [dev] API proposal for better userability in IoTivity Lite. Hi Kishen, Let me propose new APIs to satisfy followings. Two requirements : Multi Thread Application Code requirement : Easy-to use with consistent API signature Problem : Singleton CborEncoder Root object prevent creating payload in multithread race condition. - Get Response, Notify in Server side and Client side cannot be handled from different thread. It could be done by synchronization handling from App side but not easy to use. How to…. Server Side AS-IS oc_rep_start_root_object(); oc_process_baseline_interface(request->resource); oc_rep_set_boolean(root, state, state); oc_rep_end_root_object(); oc_send_response(request, OC_STATUS_OK); Server Side TO-BE CborEncoder new_rep = oc_rep_create_root_object(); // New Additional : make opaque type for CborEncoder to hide it oc_process_baseline_interface(new_rep, request->resource); // New Additional (with parameter adding) oc_rep_set_boolean(new_rep, state, state); oc_rep_end_root_object(new_rep); // we can remove this call with tinycbor update. oc_send_response(request, new_rep, OC_STATUS_OK); // New Additional (with parameter adding), refer new_rep with g_encoder. Client Side AS-IS oc_init_post(a_light, light_server, NULL, &post2_light, LOW_QOS, NULL) oc_rep_start_root_object(); oc_rep_set_boolean(root, state, state); oc_rep_end_root_object(); oc_do_post(); Client Side TO-BE // oc_init_post(a_light, light_server, NULL, &post2_light, LOW_QOS, NULL) <-- This can be skipped because params are set in new oc_do_post. CborEncoder new_rep = oc_rep_create_root_object(); oc_rep_set_boolean(new_rep, state, state); oc_rep_end_root_object(new_rep); // we can remove this call with tinycbor update. oc_do_post(a_light, light_server, NULL, new_rep, &post2_light, LOW_QOS, NULL); // New Additional (with parameter adding), refer new_rep with g_encoder, This will make API consistent with oc_do_get(……) --- Sumary New API List. --- CborEncoder_opaque oc_rep_create_root_object() oc_process_baseline_interface(new_rep, request->resource) // adding param oc_send_response(request, new_rep, OC_STATUS_OK); // adding param oc_do_post(…..) // adding param _______________________________________________ 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
