Hi Khaled, et-all,
I think last year we came already a long way in supporting development of
devices by having “getting started” via:
https://github.com/openconnectivity/IOTivity-setup
and also:
https://github.com/openconnectivity/IOTivity-Lite-setup
I think this is solving quite a bit of the issues that are mentioned below in
how to use IOTivity or IOTivity-Lite.
About the top 3 issues:
* Security/setting up acls: work is being carried out in OCF to resolve
this issue
* Presence: just do an observe on oic/res…. That should give most of the
things one wants.
* We should document this though
* Scenes: rework is going on the OCF side.
If you want to have the details, please become an OCF member (it is free)..
However this is NOT addressing the need of all the developers working on
IOTivity stack itself.
Hence filing tickets is THE thing to make the deficiencies known.
In general, there is quite a bit of work to do on all levels on the
documentation: api, architecture, etc.
Saying this, we do not need a ticket saying “improve documentation”, this is
already known.
It would be good to have ticket each time someone encounter something that is:
* Not clear
* Clearly wrong
* outdated
so that we (that includes everyone on this email thread) can do something about
it.
Kind Regards,
Wouter
From: [email protected] <[email protected]> On
Behalf Of Khaled Elsayed
Sent: Monday, December 10, 2018 7:24 AM
To: Gregg Reynolds <[email protected]>
Cc: [email protected]; iotivity-dev <[email protected]>
Subject: Re: [dev] Bad press
Thanks Gregg for your thoughtful replies. Some replies inline.
On Sun, Dec 9, 2018 at 10:14 PM Gregg Reynolds
<[email protected]<mailto:[email protected]>> wrote:
Hi Khaled,
Nice note, thanks. Not to start an endless discussion, but:
On Sun, Dec 9, 2018, 5:43 AM Khaled Elsayed
<[email protected]<mailto:[email protected]> 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 (#10065):
https://lists.iotivity.org/g/iotivity-dev/message/10065
Mute This Topic: https://lists.iotivity.org/mt/28653513/21656
Group Owner: [email protected]
Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
