Re: [Cbor] Consolidated set of tags for map-like entities

[Emile Cormier <[e-mail]>]

The benefit of using map instead of array whenever possible is better
interoperability with other decoders that ignore the tags. For example, if
I send a map tagged 132 (unordered, homogenous, unique keys), an "agnostic"
Javascript decoder will store it in a Map or Object, and the application
will at least know it's a set of key-value pairs.

The disadvantage of this approach is obviously the inconsistency. Sometimes
it's map and sometimes it's array. The decoder needs extra logic for using
the correct major type code.

On Tue, Mar 16, 2021 at 2:20 PM Joe Hildebrand <[e-mail]> wrote:

> Your approach makes sense to me.
>
> Is there any benefit to using map over array for your approach?  They're
> roughly the same on the wire.
>
> —
> Joe Hildebrand
>
> > On Mar 15, 2021, at 3:15 PM, Emile Cormier <[e-mail]>
> wrote:
> >
> > Indeed, I try to feed bytes from the wire into its resulting data
> structure as directly as humanly possible in my C++ implementation, while
> not having to write decoders by hand for every possible data structure.
> While CBOR itself is schema-less, our applications use CBOR (and JSON) to
> transfer entities with known schemas at the application level. I can
> therefore skip generating intermediate "document" trees and store the CBOR
> directly into the intended data structure (this is the idea behind
> https://github.com/OneNoteDev/GoldFish, which is partly inspiring my
> work-in-progress C++ serialization library).
> >
> > I know I could use Flat Buffers with fixed schemas, but I'd end up
> having to copy everything to standard library containers unless I'm willing
> to have Flat Buffers "infect" my entire application instead of remaining at
> the boundary. I also like the self-describing nature of CBOR for diagnostic
> purposes, plus it's easier to transcode it into JSON for web browser
> clients.
> >
> >
> > On Mon, Mar 15, 2021 at 5:21 PM Joe Hildebrand <[e-mail]>
> wrote:
> > Ah, I think I see the difference in implementation that others must
> have.  I always generically decode the data item first, *then* apply the
> tag transformation.  This allows me to return a generic Tag implementation
> if I don't support the tag, or a more-specific type or error-check if I do
> support the tag.
> >
> > Others must do special-case decoding of the data item for each tag they
> support.
> >
> > —
> > Joe Hildebrand
> >
> > > On Mar 15, 2021, at 2:09 PM, Emile Cormier <[e-mail]>
> wrote:
> > >
> > > I don't know anything about "mt5", but with my proposed tag set, you
> could check for the presence of tag 132 (homegenous key) and you would know
> after decoding the first key if all the key-value pairs can be safely
> decoded into a JS Object. Of course, this requires that the sender "play
> along" and actually bothers to use the tags.
> > >
> > > On Mon, Mar 15, 2021 at 4:44 PM Joe Hildebrand <[e-mail]>
> wrote:
> > > > On Mar 15, 2021, at 12:51 PM, Carsten Bormann <[e-mail]> wrote:
> > > >
> > > > On 2021-03-15, at 19:50, Joe Hildebrand <[e-mail]> wrote:
> > > >>
> > > >> Data Item being major type 5 should really only be used if the keys
> are homogeneously strings, in my opinion.
> > > >
> > > > We are using a lot of integer labels with mt5, so why would we make
> that restriction?
> > >
> > > This is a consequence of my implementation that others probably don't
> have.  When decoding mt5, I always keep a set of [key,value] tuples until
> all of the items have been decoded.  Then, if the keys are all strings, I
> convert the tuples to a JS Object, otherwise I convert them to a Map.  If
> I've already converted to a Map in mt5 processing, it's too late to (for
> example) throw an error if there is an unexpected duplicate key.
> > >
> > > —
> > > Joe Hildebrand
> >
>
>