You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current way that messages and options are handled is rather inefficient, as it requires cloning most CoAP options when converting from and to raw messages.
A main reason for why this is necessary is that the message types are mutable, which requires message construction to only happen at the very end.
In order to reduce this overhead and get closer to a "zero-cost abstraction", I propose making the following changes:
This might require some more involved changes, as CoAP options are represented in two different structs inside of libcoap (coap_optlist_t during PDU setup, coap_opt_t during PDU parsing)
Additionally, lifetime issues need to be considered. coap_opt_t instances are basically a view into the underlying PDU, and therefore must not outlive it.
The read-only wrappers will read option values as references from the underlying coap_pdu_t and not store them as copies (as is currently done).
There should be methods both for getting specific options (which would require a search through the option list each time) and for iterating over the list of options (maybe even supporting filters)
The write-only builders will be a wrapper around an internal coap_pdu_t for basic attributes as well as a coap_optlist_t for setting option values.
The text was updated successfully, but these errors were encountered:
The current way that messages and options are handled is rather inefficient, as it requires cloning most CoAP options when converting from and to raw messages.
A main reason for why this is necessary is that the message types are mutable, which requires message construction to only happen at the very end.
In order to reduce this overhead and get closer to a "zero-cost abstraction", I propose making the following changes:
CoapOption
type so that it acts as a wrapper around a raw CoAP option (similar to the changes toCoapUri
s in feat: improve URI handling by basing it on the libcoap type #18).coap_optlist_t
during PDU setup,coap_opt_t
during PDU parsing)coap_opt_t
instances are basically a view into the underlying PDU, and therefore must not outlive it.CoapMessage
,CoapRequest
andCoapResponse
into a read-only wrapper aroundcoap_pdu_t
(again, similar to feat: improve URI handling by basing it on the libcoap type #18) and a write-only builder structure.coap_pdu_t
and not store them as copies (as is currently done).coap_pdu_t
for basic attributes as well as acoap_optlist_t
for setting option values.The text was updated successfully, but these errors were encountered: