Re: [apps-discuss] Concise Binary Object Representation (CBOR) -- support streaming

[Phillip Hallam-Baker <[e-mail]>]

On Wed, May 22, 2013 at 9:49 PM, Manger, James H <
[e-mail]> wrote:

> CBOR [draft-bormann-cbor] looks great.
>
> The only big problem I see is that sizes have to be known upfront. You
> need to know how many bytes, array elements, or map pairs you have BEFORE
> you start encoding them. This really hinders streaming content. JSON does
> not have this limitation so CBOR should not introduce it. Removing this
> limitation would better meet objective 5: "be applicable to both
> constrained nodes and high-volume applications".
>
> This should not be hard to solve, nor to implement.
> For instance define initial bytes for "Array", "Map", "Byte array in
> parts", and "End". An array is the items between "Array" and "End". A map
> is an even number of items between "Map" and "End". There would be no need
> for the 64 initial bytes assigned to known-size versions of arrays and maps.
>
> The 32 initial bytes for known-length byte arrays would remain. The "Byte
> array in parts" initial byte would be an additional option. Between "Byte
> array in parts" and "End" can be any number of known-length byte array
> items.
>

That is the reason that DER encoding is such a major pain. Only DER makes
it even harder as the internal sizes are indeterminate...

It has to be possible to serialize and deserialize without any additional
state or pre-computation other than maintaining the position in the tree
walk.

Having to know the number of objects in a list would make transcoding from
JSON to binary form a real pig. It would be necessary to buffer objects
before you can push out the first byte.


This is the type of issue that is critical for me for an on the wire
format. Being able to index into specific content is the sort of thing I
might care about in a storage format. I might care about things like byte
alignment as well. Or maybe not.

-- 
Website: http://hallambaker.com/