Ashok, Thank you for asking. I don?t believe it is appropriate to push my mods to master because:
1) It?s a major rework of the code, which nearly every file modified, so merging with master would be a huge amount of work. 2) I haven?t worked on it in several months. The basis of the work was late 1.0.0, and I updated it to be compatible with 1.0.1, it hasn?t seen any work since then, so it doesn?t work with 1.1.0. 3) I am retiring this month, so I can?t put much work into it. OTOH, I believe it could be the starting point for IoTivity Lite. It could also be the basis of an alternative implementation of the OCF standard if such a thing were to be needed. That said, I am looking for a place to archive the work. I am certainly willing for the IoTivity organization to have the code for reference and any other use. The code is recognizable to anyone familiar with IoTivity master, so lessons can be learned. The biggest lesson is how to eliminate most of the 200 mallocs in IoTivity, which will be important at some point. The size reduction is secondary, but it eliminates a lot of processing overhead (copying structures) that puts a load on small server nodes. If you have a place for it somewhere, let me know, and I?ll put it there along with some commentary. But do it quickly. I did the work as an Intel employee, and after 6/21 I won?t be able to give you the code. John From: ASHOKBABU CHANNA [mailto:[email protected]] Sent: Tuesday, June 07, 2016 4:09 AM To: Light, John J <john.j.light at intel.com>; Gregg Reynolds <dev at mobileink.com>; iotivity-dev at lists.iotivity.org Subject: Re: Re: [dev] libchibi John, How about pushing your modifications in master and see how it is reducing the code size ? I think it is the right time as IoTivity release 1.2 is planned in September.. Regards, Ashok ------- Original Message ------- Sender : Light, John J<john.j.light at intel.com<mailto:john.j.light at intel.com>> Date : Jun 06, 2016 20:57 (GMT+05:30) Title : Re: [dev] libchibi Gregg, I did a similar thing a few months back, but it took more than a weekend. ? I removed all duplicate data structures and all the copying among them. I combined all smaller structures into a couple of transaction buffers, eliminating nearly all malloc/free calls. The result is half the code size and nearly immune to malloc failures, and it talked with IoTivity 1.0.1. I don?t know what to do with mine, either. John Light From: iotivity-dev-bounces at lists.iotivity.org<mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:[email protected]] On Behalf Of Gregg Reynolds Sent: Monday, June 06, 2016 7:04 AM To: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: [dev] libchibi You know you're a hopeless geek when you: A. Spend all day Saturday reorganizing a codebase and build system that already works, just for fun. B. Tell people about it. libchibi<https://github.com/iotivation/libchibi> Why? I found the code structure and build system of Iotivity mildly opaque, and I got to wondering whether it would be possible to more cleanly separate the c kernel from the c++ stuff. In my ideal world, the c kernel would be a separate thing, and the c++ stuff, as a higher-level layer, would be just another SDK, just like a Java or Lua or Javascript SDK. For example to get Iotivity running on a very constrained device you might want to leave some stuff out, and include only the minimal functionality you need. I get the feeling Iotivity is already designed to support that sort of thing but it's been kinda hard for me to see how it all fits together and how to pull it apart. So anyway having acquired a basic understanding of the build system and structure from porting it to Darwin I decided to go crazy and see how hard it would be to turn resource/csdk into a kind of standard c project, with the usual include/, lib/, src/ directories, etc. Not that hard, it turns out. What's there compiles but has not been extensively tested and might have problems. And I'm not sure csdk has all the functionality required for it to be called an OIC implemenation. I don't know how far I'm going to go with this, but in the next two weeks I'm going to try to get Iotivity running on Zephyr on the Arduino 101. maybe with libchibi as well as the official code. Not intended as a fork, but it occurs to me that it might be a Good Thing if it did turn into a fork. IETF requires two independent implementations for a protocol to advance to a standard; that seems like a Good Thing for OIC as well. libchibi is hardly independent, but still it seems like it would be a good thing to have two different projects at least. Cheers, Gregg ---------------------------------------------------------------------------------- Sr. Technical Manager, Software Architect. SRI-B, IoT Division/ IoTivity, Samsung Electronics Co., Ltd. +91-9880709710 ---------------------------------------------------------------------------------- [cid:image001.gif at 01D1C09A.34F71680] [http://ext.samsung.net/mailcheck/SeenTimeChecker?do=9226f2572c3ad11722ab35b690639e7f69346c485ba2369da1889aa8efbbee47738ed17e7639ce1f641b1a8c451b073656239170f5eb4b5c326bbdfb2ea96a2fcf878f9a26ce15a0] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160607/b6659c4a/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13168 bytes Desc: image001.gif URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160607/b6659c4a/attachment.gif>
