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:
[ ] Rewrite the CoapOption type so that it acts as a wrapper around a raw CoAP option (similar to the changes to CoapUris in #18).
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.
[ ] Separate CoapMessage, CoapRequest and CoapResponse into a read-only wrapper around coap_pdu_t (again, similar to #18) and a write-only builder structure.
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 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:
CoapOptiontype so that it acts as a wrapper around a raw CoAP option (similar to the changes toCoapUris in #18).coap_optlist_tduring PDU setup,coap_opt_tduring PDU parsing)coap_opt_tinstances are basically a view into the underlying PDU, and therefore must not outlive it.CoapMessage,CoapRequestandCoapResponseinto a read-only wrapper aroundcoap_pdu_t(again, similar to #18) and a write-only builder structure.coap_pdu_tand not store them as copies (as is currently done).coap_pdu_tfor basic attributes as well as acoap_optlist_tfor setting option values.