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

Ken Bannister notifications at github.com
Fri Apr 5 03:50:05 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);

> As clif_decode_link only decodes one link per call, cord_lc_read_res can be used as a wrapper to it to decode all the links at once and returns it to the user.

That's the resource intensive part. ;-) By iterative I meant that it would be less intensive for the user to repeatedly call `cord_lc_read_res()` with the output from the query, and receive one clif_t link per call. Maybe the cord_lc_rd_t parameter could remember the last character read from the query result, as well as remember the last block number it retrieved.

Let's wait for clif, and I'd be happy to discuss more.

-- 
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/10222#discussion_r272423451
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190404/3c6a4a76/attachment.html>


More information about the notifications mailing list