Here are the (rather abridged) notes from the CoAP brainstorming session at the RIOT summit 2023
Summit 2023 breakout: CoAP future brainstorming
Notetaking: emmanuel
chrysn: Presents his assorted ideas about driver-based CoAP, possibly on top of existing implementations
martine: I need to check in the app if the context format is what I expect. THat’s not good
chrysn: the level of abstraction we have is responsible for that. Would be good to have a higher level abstraction. However the dispatch should benefit from being at lower level.
martine: yes, in my dns over coap implem it would help quite a bit
chrysn: the question is how to do that best, have no concrete ideas yet on that.
martine: ideas? input on that? Anyone?
chrysn: had a precursor discussion on that in helsinki, but since then, nanocoap and gcoap have drifted farther apart
martine: will you use C or Rust? Traits could be a benefit here
chrysn: I expect to do some prototyping in Rust, but should also have a non-Rust version. Most importantly we need a concrete proposal
Michel: is there a concrete/strong reason to have these interfaces separated?
chrysn: gcoap and nanocoap fundamentally differ on client side for instance.
Ben: one confusion is about the fact that nanocoap is message parser for… gcoap
chrysn: not too much a fan of nanocoap sock approach
Ben: could keep the nanocoap sock open and pass around
chrysn: but this does not really work for the server side
Karl: so downside of gcoap is it requires an extra thread. downside of nanocoap is it is not so practical for server side
Ben: seems to me that gcoap is a lot less maintainable than nanocoap
chrysn: have different experience, I get timeout if I send a too large message to nanocoap, whereas it is fixed in gcoap (get proper error message) since quite some time
chrysn: should we deprecate some stuff here? Do we still have the tools to do that? (We used to do that at some point, although not so easy in C)
martine: a macro or something?
Emmanuel: need to wrap up
chrysn: key takeway: if you use coap, watch out for deprecation messages.
martine: session was meant to be more brainstorming anyways
chysn: can Michel send over a pointer to his student exercices with CoAP?
martine: maybe we could partly work on that for the upcoming Prague IETF hackathon? With willing students too?
a) the current situation of having two popular CoAP stacks that have highly ambiguous borders and compatibility lines is confusing (and getting worse because while there is some unification going on, at the same time features are added without regard for any unification attempts), and
b) to do any transports outside UDP and DTLS (and the DTLS is already subtly non-compliant), we’ll need some more driver-ish access to messages. As elaborated in my CoAP plumbing talk, lots of things can differ by transport, so all access to messages needs to go through functions that can eventually dispatch to a driver that serializes messages the way the transport needs it. There have been some changes already that reduce how often CoAP users need to reach into a coap_pkt_t struct (rather than treating it as an opaque item), but eventually those will all need to be gone before we can support CoAP over TCP, over BLE or OSCORE – at least without the applications specializing on the transport in the code, which is possible but I’d consider that an abomination (and am deeply saddened that that’s still the only way to use libOSCORE).
One point that I was only reminded of again on this weekend: We have a similarly invisible divide between “parsed CoAP packet” and “written CoAP packet”, which both use the same coap_pkt_t, but have different invariants, so that only some functions work with them. That, too, could need some cleanup; unlike on the nanocoap/gcoap side where I advocate unification, I’m unsure as to whether a clear distinction (different types, even if in the implementation it boils down to the same struct) wouldn’t be the better choice.
I agree, I’ve attempted to do this before but because nanoCoAP and GCoAP use coap_pkt_t in subtly different ways, this would solidify the divide between the two implementations (or require an even larger undertaking at unification).
