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 separation of buffer (with its end) and length already allows having nanoCBOR encoded into the first block of a CoAP block-wise response. Would it be reasonable to extend the encoder by a field that counts how many initially encoded bytes to discard? (Similar to how the produced length tells how many bytes were discarded after the buffer).
I don't have a full use case yet, but looked at @silkeh's RIOT-OS/RIOT#17571, and that would appear to work great with CoAP block-wise. So this is not a full feature request yet, more like a "would it make sense to add this feature?"
(And it may happen that the next request is then for a checksum field that all the input is fed into, which would then generate ETags to detect whether the blocks can even be assembled).
The text was updated successfully, but these errors were encountered:
The separation of buffer (with its end) and length already allows having nanoCBOR encoded into the first block of a CoAP block-wise response. Would it be reasonable to extend the encoder by a field that counts how many initially encoded bytes to discard? (Similar to how the produced length tells how many bytes were discarded after the buffer).
I don't have a full use case yet, but looked at @silkeh's RIOT-OS/RIOT#17571, and that would appear to work great with CoAP block-wise. So this is not a full feature request yet, more like a "would it make sense to add this feature?"
(And it may happen that the next request is then for a checksum field that all the input is fed into, which would then generate ETags to detect whether the blocks can even be assembled).
The text was updated successfully, but these errors were encountered: