[riot-notifications] [RIOT-OS/RIOT] net/coap: Add Link Format attributes to resources (#11328)

Ken Bannister notifications at github.com
Thu Apr 4 15:01:59 CEST 2019


Thanks Kaspar for the creative adaptation of a resource/request handler. I see these plusses and minuses and questions for this approach:

+++ A callback function provides more flexibility in the response.

+++ It's useful to localize knowledge about a resource, in this case to the handler function.

??? How do you write the path link, like '</node/info>'? Does the callback handle this?
If so, this requires some way for it to access the `coap_resource_t` struct, right? Otherwise you must duplicate/reference that string. If the callback does not write the link, then I expect you lose flexibility for the subtree handling case.

??? Assuming there is a good answer for the previous item, can a handler simply not define handling for link format, which means there are no extra link format parameters to write?

--- It is confusing and potentially a source of conflicts to have one function with different purposes and contexts. For example, the `coap_pkt_t` provides important context for traditional response handling. If this were a '/.well-known/core' request that included Uri-Query options, would this handler be responsible for determining whether it is "filtered out" of the response? 

--- cord_ep acts as a CoAP *client* when registering with an RD. So, it assembles the link format description for a node as part of building the payload for the POST request, via `gcoap_get_resource_list()`. In other words, we may need this link format content outside the context of a server handling a request. This requirement can lead to confusion for a handler. Is it writing a response or a request? What is the content of the coap_pkt_t parameter?

--- Keep in mind that the current `coap_well_known_core_default_handler()` already operates as a blockwise response. How would the required context be passed to the handler?

My overall conclusion is based on the use cases of link format in a constrained node. I see use of link format as an accessory and not part of the central purpose for a node. A resource directory (RD) is designed to be a repository for this sort of information. So, I think a primary use case for a node is simply to push this metadata to an RD. This is what cord_ep and cord_epsim do. Altering the content of `coap_resource_t` and the definition of `coap_handler_t` is risky. Combining the purpose of the request handler for these two purposes creates a dependency that limits our flexibility in the future, and I don't think it's worthwhile for this purpose.

I would be in favor of doing something like the 'Capable, dynamic case' in my [comment](https://github.com/RIOT-OS/RIOT/issues/11171#issuecomment-478348346) in #11171. In other words, let's allow for a callback function for /.well-known/core and RD registration, but keep it focused to the context of building a formatted list of resources rather than multiplexing the main request handler. In this solution, we would rework `coap_well_known_core_default_handler()` and `gcoap_get_resource_list()` to loop through resources and call a function for each.

This could be a single function, and provide the link format parameters as an attribute in coap_resource_ext_t as I described in a [comment](https://github.com/RIOT-OS/RIOT/pull/11328#issuecomment-479429918) above :

```
ssize_t encode_resource(const coap_resource_ext_t *res_ext, uint8_t *buf, size_t maxlen, uint8_t format)
```

Or, we could use coap_resource_ext_t to let the user define a function, like the current `coap_handler_t`, that writes the link format content. Either way, I would like to keep standard request handling separate from writing resource metadata.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/RIOT-OS/RIOT/pull/11328#issuecomment-479887422
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190404/e81604a7/attachment.html>


More information about the notifications mailing list