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

Ken Bannister notifications at github.com
Tue Apr 16 12:36:22 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);

Thanks for the link. I actually saw that earlier but thought, "why do we need this when we already have block"? Looking at it more closely, I see that the interface is super simple for a client and eliminates the need for the client to stitch 'sliced' links together from block's fixed size response. On the other hand, if packet space is really limited, block provides certainty in the quantity of data received.

It might actually be worthwhile to ask the core mailing list about the reasoning. If we're concerned about data size, use of CBOR would be valuable here, but I guess that use is orthogonal to how the data is sliced. I also agree with you that we don't need to resolve this issue today.

-- 
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_r275734396
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/notifications/attachments/20190416/22e15c4c/attachment.html>


More information about the notifications mailing list