[riot-notifications] [RIOT-OS/RIOT] net/nanocoap: iterate options (#12074)

chrysn notifications at github.com
Thu Sep 12 13:20:22 CEST 2019

On Thu, Sep 12, 2019 at 03:52:22AM -0700, Ken Bannister wrote:
> I'm not concerned that we are packing the option number and the offset
> into a single parameter. We're trying to perform a task that's more
> complex than coap_opt_get_opaque() in a constrained environment.

My concern was not so much about the option number being a delta or an
option number, but more about whether it makes sense to access it as a
struct member rather than via an accessor. But (at least before we go to
extensibility, see below) that's more of an API design question (like
the below with intitializer-and-simple-next vs.
next-that-can-initialize), and if this fits the RIOT style, so be it.

> - COAP_OPTGET_FIRST -- get the first option
> - COAP_OPTGET_NEXT -- goto offset in coap_opt_pos_t
> - COAP_OPTGET_OPTNUM -- find opt_num in coap_opt_pos_t, internally with coap_find_option(). In this case, the output value of opt->opt_num still will be the delta from the previous option.

Good idea, that makes the "get next option" part more like a general

> As I think about OSCORE, it seems like we're going to need another
> function anyway. It may be that we want to read options from some
> buffer in a different location, like the inner options in the payload.
> In that case we can use something like:

That could be a helper usable by the OSCORE library, but it probably
won't use it in its first iteration given that not all libraries can
supply it easily.

My concern for extensibility is rather that for an OSCORE message, the
struct to iterate over would be differently shaped as it'll contain two
cursors (one inside and one outside), and that having a client reach
into its opt_num may not be so easy to work with any more. But we'll
know more about that with the upcoming proposal on deep-integration.

(ie. I'm happy with COAP_OPT_GET_ initializers, but not so much with
users accessing its opt_num value. It's probably workable just a bit
harder, we'll see that then.)

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/20190912/b6134bb3/attachment.htm>

More information about the notifications mailing list