Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support definite-length Arrays and Maps in CBOR #1955

Open
wverdese opened this issue May 30, 2022 · 4 comments
Open

Support definite-length Arrays and Maps in CBOR #1955

wverdese opened this issue May 30, 2022 · 4 comments
Labels
feature up for grabs A good issue for external contribution

Comments

@wverdese
Copy link

wverdese commented May 30, 2022

What is your use-case and why do you need this feature?
I want to use this library to communicate with an API that uses CBOR for payloads. This API is strictly requesting Arrays and Maps to be encoded with a definite length, because of / lack of dynamic memory allocation.
Encoding a Kotlin Array or a Kotlin Map will always result in their indefinite-length counterpart, so the API will fail when decoding my payload.

Describe the solution you'd like
This line:

Cbor.encodeToByteArray(arrayOf(mapOf(\* stuff *\)))

now serializes to:

9F                                  # array(*)
   BF                               # map(*)
      /* stuff */
      FF                            # primitive(*)
   FF                               # primitive(*)

I'd like to be able to, e.g., pass a parameter:

Cbor.encodeToByteArray(arrayOf(mapOf(\* stuff *\)), Lengths.DEFINITE)

to be able to change the serialization to:

81                          # array(1)
   A1                       # map(1)
      /* stuff */
@sandwwraith
Copy link
Member

Well, any CBOR decoder should support indefinite lengths, otherwise it does not satisfy the standard. But probably some tuning may help here

@sandwwraith sandwwraith added the up for grabs A good issue for external contribution label May 30, 2022
@wverdese
Copy link
Author

I agree, but there's also the efficiency aspect to consider. For instance, I'm using CBOR to send/receive messages over BLE. Using indefinite lengths in a context where the length is very well known will result in two extra bytes to exchange (the list+map delimiters) that are not necessary.

@extemporalgenome
Copy link

This also informs decoder allocation efficiency: a consumer (in languages where it matters or can well take advantage of it) can allocate the exact size data structure needed when given a definite length, and without requiring any buffering to count the overall length before decoding and storing the data in memory.

@JesusMcCloud
Copy link

see #2412

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature up for grabs A good issue for external contribution
Projects
None yet
Development

No branches or pull requests

4 participants