[riot-notifications] [RIOT-OS/RIOT] net: add CoRE RD lookup client implementation (#10222)

Ken Bannister notifications at github.com
Mon Apr 1 04:19:17 CEST 2019

kb2ma commented on this pull request.

> +ssize_t cord_lc_ep_raw(const cord_lc_rd_t *rd, uint8_t content_format,
+                   char *result, size_t maxlen);
+ * @brief Look for registered resources at a RD server
+ *
+ * @param[in]  rd               the target RD server
+ * @param[out] resources        list of resources at @p rd
+ * @param[in]  limit            max number of resources prepared to receive
+ *
+ * @return number of found resources on success
+ * @return CORD_LC_NORSC if there is no resource lookup interface at @p rd
+ * @return CORD_LC_TIMEOUT if lookup timed out
+ * @return CORD_LC_ERR on any other internal error
+ */
+ssize_t cord_lc_res(const cord_lc_rd_t *rd, cord_lc_res_t *resources, size_t limit);

This function is resource intensive. I would consider an iterative function on the collected string from coap_lc_res_raw().

cord_lc_read_res(const char *source, clif_t *link)
where link is the output parameter. However, this function is similar to `coap_decode_links()` from #11189, so not that useful. 

On the other hand, I would not be surprised to see a block based response from the RD. How to incorporate the possibility into the API? Rather than separately call `cord_lc_res_raw()` first, maybe something like this:

cord_lc_read_res(const cord_lc_rd_t *rd, char *input, unsigned input_len, clif_t *link)
where the cord_lc_rd_t param could be extended to include the block number. That means it could transparently retrieve the next block.

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/61fb1028/attachment.html>

More information about the notifications mailing list