Hi Khaled, Nice note, thanks. Not to start an endless discussion, but:
On Sun, Dec 9, 2018, 5:43 AM Khaled Elsayed <khaledi...@gmail.com wrote: ... > 1) The specs are complex. Does a simple IoT device need to support all of > this? > Good question, one I think many device devs will ask. I'll take a stab: it depends. :) Do you want the benefits of OCF? Then the complexity is unavoidable. Imho OCF has done an excellent job of modeling this very complex problem space. It's as complex as it needs to be, but my take on it is that OCF is not adding a lot of incidental complexity. It's the problem that is complex. Otoh, I'd suggest a slightly different question: if I want my device to play nice in an OCF environment, does it have to include all this complex stuff? I think the answer is no. My impression is that the OCF folks have given this a lot of thought. E.g. the bridging specs. 2) Documentation is lacking. Sometimes (actually often) code is not in > synch with web documentation. Only very simple issues/examples are well > documented. No complete developers guide available. API's are documented > yes, but this is not enough. > What are the three most important doc issues for you? Me, I think I'd go with 1) security stuff - creds, acls, provisioning how to use certificates, roles, etc. 2) presence (advertisement discovery?) 3) Scenes. 3) Complex source code tree and strong but not very familiar build tool > (scons). Then code reviews on gerrit then another (JIRA) for tickets. Then > you find source code on github but pull requests are not used there. Go to > gerrit or JIRA to merge code or raise issues. > I'm guessing that's just a fact of life for Iotivity. Fwiw I'm addressing this in openocf by reorganizing the code and eliminating the quasi-OO code in csdk. But I don't see any of that moving into Iotivity, too much work. Maybe some bits. Otoh the notes I keep may be helpful for devs digging into the source. 4) Logs are long and not-very-configurable what to log and what not to log > (difficult to debug). Not to mention that the output to debug is nested in > a very long path due to all the supported platforms. > I think this is very addressable. It's quite easy to conditionalize logging with a few macros. E.g. #ifdef DBG_MSGS in camessagehandler.c - I don't always need to see pdu dumps. Another thing that isn't terribly hard but very useful is providing an option to log to a file. You need that if you want to e.g. implement an ncurses interface. HTH, Gregg > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10059): https://lists.iotivity.org/g/iotivity-dev/message/10059 Mute This Topic: https://lists.iotivity.org/mt/28653513/21656 Group Owner: iotivity-dev+ow...@lists.iotivity.org Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
