[riot-notifications] [RIOT-OS/RIOT] sys: Add Link Format module (#11189)

Ken Bannister notifications at github.com
Mon Apr 1 02:29:24 CEST 2019

I agree that the additions to the link format implementation warrant the separate module in this PR. It also makes sense for gcoap and nanocoap to use this API, and it's proably worth a separate PR for that work.

I added a [comment](https://github.com/RIOT-OS/RIOT/issues/11171#issuecomment-478348346) to #11171 on extending CoAP resources. Given the use cases there, I favor the lower level aspects of the clif API. The functions provide a stream-like API where the client provides or collects the input, and then loops through it to execute the functions to read/write the target and params.

For encoding, `clif_add_target()`, `clif_add_param()`, and `clif_add_link_separator()` are necessary. `gcoap_get_resource_list()` provides an example of looping through the resources, but it needs `clif_add_param_list(const char *list)` since it likely already is encoded for each `coap_resource_t` as suggested in #11171.

For decoding, use `clif_get_target()` and `clif_get_param()` over an input string. For resource lookup in #10222, the source string could be collected with `cord_lc_res_raw()`.

Beyond these functions, for `clif_decode_links()`, how to predict the number of links and params to expect, and why use all that memory up front? Maybe just a singular `clif_decode_link()` is sufficient. This logically matches to `clif_encode_link()`.

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/b6c855be/attachment-0001.html>

More information about the notifications mailing list