[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:
-------------- 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