Hi, folks (and specially addressing Thiago),
Regarding tinycbor, is there a strong reason for the cbor.h header to
be named like that? The lib is named "tinycbor" anyway ("-ltinycbor"
at its pkg config template file), so I guess it would not hurt to
rename that .h file to that. One reason is that it collides easily
with other cbor implementations, like the cbor.h in the RIOT OS. We
could have hacks to avoid collision or ask those guys to rename as
well, but once it may make sense to exchange it here, I'm asking
first.
Also, looking at its TODO file, I see "Add API for creating
indeterminate-length arrays and maps". What would that be? Currently,
issuing tinycbor encoder calls with a NULL buffer and 0 as size works
well for calculating the resulting encoded buffer's lenght, but it's
still limited for some kinds of usage. At Soletta, for example, our
OIC infrastructure is so that we expose callbacks for user-registered
OIC resources where he/she may add content (cbor-encoded, naturally)
to an encoder context, to be bundled as a final CoAP packet. However,
we can't have a user callback issued two times, just to have a 1st
phony run calculating that size. We should think of how to improve
that at tinycbor's side, too.
Best regards,
--
Gustavo Lima Chaves
Intel - Open Source Technology Center
