Thanks Gregg for your thoughtful replies. Some replies inline.
On Sun, Dec 9, 2018 at 10:14 PM Gregg Reynolds <d...@mobileink.com> wrote: > 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. > KE>> I agree the problem is complex. But sometimes it is better to start small and grow the system/specs after the adoption is there. I also agree that bridging can help but it is not very well presented within IoTivity code. > > > 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. > KE>> I will add the details about all these (endless) default resources created within a device and what they serve to do and the related introspection (which sounds like a scary term :)) and then some simple examples with good documentation on support of legacy or non-OCF devices. > > 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. > KE>> It is a fact of life but it is a problem that needs to be fixed. > > 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. > KE>> Exactly, I remember to have done something to fix this in one of the releases maybe in 2016 but lost as I upgraded to following releases without migrating the code. I should have contributed it back to the project then. It was very primitive so that's why maybe I was reluctant to share. > 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, > It did. Best regards, Khaled > > Gregg > >> -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10064): https://lists.iotivity.org/g/iotivity-dev/message/10064 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] -=-=-=-=-=-=-=-=-=-=-=-
