Open mlasch opened 3 years ago
@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 ?
Yes definitely. The discussion should also cover how to interact more easily with objects on the client side from the "application".
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.
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).
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 likelwm2m_data_parse
andlwm2m_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:
<->
This may imply major changes, so this issue is intended to collect and discuss ideas on how to improve the overall usability. Any thoughts?