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?
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?