On Thu, Sep 12, 2019 at 03:52:22AM -0700, Ken Bannister wrote:<br>
> I'm not concerned that we are packing the option number and the offset<br>
> into a single parameter. We're trying to perform a task that's more<br>
> complex than coap_opt_get_opaque() in a constrained environment.<br>
<br>
My concern was not so much about the option number being a delta or an<br>
option number, but more about whether it makes sense to access it as a<br>
struct member rather than via an accessor. But (at least before we go to<br>
extensibility, see below) that's more of an API design question (like<br>
the below with intitializer-and-simple-next vs.<br>
next-that-can-initialize), and if this fits the RIOT style, so be it.<br>
<br>
> - COAP_OPTGET_FIRST -- get the first option<br>
> - COAP_OPTGET_NEXT -- goto offset in coap_opt_pos_t<br>
> - 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.<br>
<br>
Good idea, that makes the "get next option" part more like a general<br>
tool.<br>
<br>
> As I think about OSCORE, it seems like we're going to need another<br>
> function anyway. It may be that we want to read options from some<br>
> buffer in a different location, like the inner options in the payload.<br>
> In that case we can use something like:<br>
<br>
That could be a helper usable by the OSCORE library, but it probably<br>
won't use it in its first iteration given that not all libraries can<br>
supply it easily.<br>
<br>
My concern for extensibility is rather that for an OSCORE message, the<br>
struct to iterate over would be differently shaped as it'll contain two<br>
cursors (one inside and one outside), and that having a client reach<br>
into its opt_num may not be so easy to work with any more. But we'll<br>
know more about that with the upcoming proposal on deep-integration.<br>
<br>
(ie. I'm happy with COAP_OPT_GET_ initializers, but not so much with<br>
users accessing its opt_num value. It's probably workable just a bit<br>
harder, we'll see that then.)<br>


<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/RIOT-OS/RIOT/pull/12074?email_source=notifications&email_token=ABE7WYBR2ZDMOT3ATMZFGRTQJIQXNA5CNFSM4IPGBY3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6RRDNQ#issuecomment-530780598">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABE7WYGPC7FGVMSKG7MV4WDQJIQXNANCNFSM4IPGBY3A">mute the thread</a>.<img src="https://github.com/notifications/beacon/ABE7WYEMXTQ5MP7X7YNT423QJIQXNA5CNFSM4IPGBY3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6RRDNQ.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/RIOT-OS/RIOT/pull/12074?email_source=notifications\u0026email_token=ABE7WYBR2ZDMOT3ATMZFGRTQJIQXNA5CNFSM4IPGBY3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6RRDNQ#issuecomment-530780598",
"url": "https://github.com/RIOT-OS/RIOT/pull/12074?email_source=notifications\u0026email_token=ABE7WYBR2ZDMOT3ATMZFGRTQJIQXNA5CNFSM4IPGBY3KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6RRDNQ#issuecomment-530780598",
"name": "View Pull Request"
},
"description": "View this Pull Request on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>