Wakaama needs a more abstract API

[mlasch]

In order to simplify the usage and lower the entry barrier to Wakaama, I think the way of how to interact with library data structures should be reworked. E.g. currently, on the server side, each implementation (examples and custom builds) have to handle the raw buffer. The buffer can contain all different content formats and parsing has to be implemented for each new application. There is already the lwm2m_data_t structure in place which can hold IPSO objects independently of the content format in a tree structure. Also functions like lwm2m_data_parse and lwm2m_data_serialize are available. However they are a bit cumbersome to use, partly because in addition to the pointer to the structure there is also the size variable which have to be tracked. A clean interface would help a lot.

Some ideas:

• Modify the result callback to hide the raw buffer and do the parsing before the call (this assumes that all chunks of a block transfer can fit in memory):

  typedef void (*lwm2m_result_callback_t) (uint16_t clientID, lwm2m_uri_t * uriP, int status, block_info_t * block_info, lwm2m_media_type_t format, uint8_t * data, int dataLength, void * userData);

  <->

  typedef void (*lwm2m_result_callback_t) (uint16_t clientID, lwm2m_uri_t * uriP, int status, block_info_t * block_info, lwm2m_data_t * lwm2m_data, int size, void * userData);

• Use a single structure which holds all important data like uri, parsed tree, size, status etc.
• As described in #521 the interface is already misused to report the notify counter via the status field.
• The callback should still allow access to the raw buffer if needed
  • If the chunks of a block transfer have to be treated individually
  • If parsing fails and custom parsing is needed
• It should be possible to disable the parsing (at build time?) due to memory concerns

This may imply major changes, so this issue is intended to collect and discuss ideas on how to improve the overall usability. Any thoughts?

[sbernard31]

@sbertin-telular, @qleisan, @tuve do you think some of this idea makes sense ?

@mlasch if dev team agree with some of your ideas do you plan to contribute it or you just share the idea ?

[qleisan]

Yes definitely. The discussion should also cover how to interact more easily with objects on the client side from the "application".

[sbertin-telular]

On the client side one thing that would be helpful is to allow writes to be local or remote. Local writes might have more access. For example, assume a resource that holds the current temperature. This should be writable locally, but not remotely. Right now a separate function is needed to modify the value in the object when a new reading is made.

Taking it further, an abstract interface for objects in general might make implementing new objects easier. I'm thinking registering an object would also register the resources and types. Wakaama would handle storage of the values and notification back the the application of changes in values, attributes, etc. My concern with this would be needing extra flash and/or RAM on a device.

[sbernard31]

On the client side one thing that would be helpful is to allow writes to be local or remote.

Just to share some idea :
In Leshan, I'm not totally satisfy of the API but we have an object which defined the "Identity" of the peer which do the "request". This allow us to know if write/read/exec is requested by a Bootstrap or LWM2M server. The idea was also to be able to implement ACL later. We also have a "special" identity called SYSTEM which have all the right (like writing temperature).