issues related to "add new object"

[qleisan]

Listing observations/issues found while supporting #516

1. inconsistent naming of files, e.g. "object_security.c" (the norm) vs "test_object.c"
2. client "disp" command is guarded by "#ifdef WITH_LOGS" and the user experience is not great if you don't build for debug - no output at all...
3. help dump => "dump URIURI: uri of the Object or Instance such as /3/0, /1" -- typo (help messages for different commands have somewhat different formatting that could be aligned)

Any comments?

And then the bigger question about how to provide a better abstraction/interface for a new user that wants to add a new object. Any thoughts on this topic and the balance between improvements / "don't break legacy".

[qleisan]

@sbertin-telular any comment regarding the implementation of the "disp" command? Not all objects implement the display_XXX_object() function and those that do are guarded by #ifdef WITH_LOGS.

Is this a sound way forward

• remove the WITH_LOGS guard OR implement a user message that output is suppressed
• implement a user message for objects that have no display function (not implemented or not relevant?)
• implement an error message if "disp "

[sbertin-telular]

I hadn't thought much about the "disp" command before. I think removing the #ifdef WITH_LOGS for the display functions is good as those are always by request anyway. The check should remain for printing the contents of messages sent. The rest of what you proposed sounds good also.

[sbernard31]

And then the bigger question about how to provide a better abstraction/interface for a new user that wants to add a new object. Any thoughts on this topic and the balance between improvements / "don't break legacy".

I think it's depends of what will be decide at : #487
(support LWM2M 1.0 or not, maintaining v1.0 or NOT, breaking API or not.)

About "providing a better abstraction/interface for a new user that wants to add a new object", maybe a dedicated issue could be created where we list what are problem of the current API and how a new one could help to solve it (or something like this).

[qleisan]

I agree, "new object API" is a separate issue that should have its own thread.

[sbernard31]

@qleisan, this issue was close automatically because of "fixes" wording in #518 description.

Is this really fixed or should I reopen it ?

[sbertin-telular]

I think 1 (#519) and 2 (#518) were taken care of, but 3 remains.

[qleisan]

Not needed, minor issue that can be fixed next time together with other "help text improvements"