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

[Joe Hildebrand <[e-mail]>]

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
>