[riot-notifications] [RIOT-OS/RIOT] Add further description of CoAP resources (#11171)

Ken Bannister notifications at github.com
Sun Mar 31 16:48:03 CEST 2019

To determine the best way to further describe CoAP resources, we need to identify the main use cases for this description. In general I am wary of mandating inclusion of *any* additional state for metadata for a constrained node. I think the simple scenario mostly pushes resource state off to a resource directory or other store on some more capable machine. I agree with the resource directory draft that a separate commissioning tool is likely to push this data to the RD.

Simple, static case
Besides the case of external management, a simple node may know some static state about its resources. In this case the simple state includes basic insights into the resource, like resource type and content type. 

I would use the simplest approach that could work in this situation. I suggest addition of a new attribute to `coap_resource_t` that includes the parameter text already encoded in link format, like you describe in Idea 3:

typedef struct {
    const char *path;               /**< URI path of resource               */
    unsigned methods;               /**< OR'ed methods this resource allows */
    coap_handler_t handler;         /**< ptr to resource handler            */
    void *context;                  /**< ptr to user defined context data   */
    const char *clif_params;        /**< link format attributes             */
} coap_resource_t;

which looks like this example when used:

static const coap_resource_t _resources[] = {
    { "/cli/stats", COAP_GET | COAP_PUT, _stats_handler, NULL
      , .clif_param = "rt=counter;ct=40"

I would make these parameters compile-time optional to avoid burdening the simplest scenarios that don't need them at all. Use of `const` also means the attribute string is stored in read-only memory with the rest of the resource. In this scenario a parameter like 'sz', that might change, could just use a value guaranteed to be large enough.

This approach makes it simple to write parameters to a resource directory in this scenario. Simply append the literal from the resource array as the parameters.

Capable, dynamic case
A more capable scenario is use of a framework like LwM2M, where state is maintained internally, but also may be pushed to an external data manager. In this case, the state manager that will be able to interpret resource state in a generic way to write the state dynamically in link format.
In this situation, I don't think changes are needed to the `coap_resource_t`. The entity responsible for writing the links will know how to handle resources in a generic way. So maybe any conditional code for this scenario would reside in `gcoap_get_resource_list()` or similar. Maybe there would be a handler like in Idea 2 in the issue description. Notice the function below adds a `coap_resource_t` argument.

ssize_t get_resource_desc(const coap_resource_t *resource, uint8_t *buf, size_t maxlen, uint8_t format)

We likely would want a compile time constant to identify this scenario, something like, `NANOCOAP_CLIF_DYNAMIC`.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190331/4f9c53ea/attachment.html>

More information about the notifications mailing list