Re: [Json] Proposed minimal change for duplicate names in objects

[Tim Bray <[e-mail]>]

I’ll assume you’re right when you say dupe detection has been measured as
expensive at run time, but I’m thinking that if I were writing a reader I'd
implement a hash table with a test-and-set method, so I admit I'm surprised
by the finding.  I think I’d need to see a little more research before I’d
accept that as a given.  -T


On Sat, Jul 6, 2013 at 9:37 PM, Tatu Saloranta <[e-mail]> wrote:

> On Sat, Jul 6, 2013 at 7:57 PM, Nico Williams <[e-mail]>wrote:
>
>> On Sat, Jul 6, 2013 at 8:44 PM, Tim Bray <[e-mail]> wrote:
>> > This feels like a no-brainer to me, but that’s probably because (as I’ve
>> > said before) I’m an API guy, and the only use for JSON objects in my
>> world
>> > is to transfer a hash table or database record or whatever from here to
>> > there, and there, and in such a situation dupes can never be useful or
>> > intended and can only be a symptom of breakage (or, in the JOSE case, a
>> > symptom of a malicious attack on my crypto).
>>
>> I agree.  As a security guy I would prefer if one way or another we
>> end up with no dup names, but as an "API guy" myself I think of the
>> streaming parsers (they offer an API after all).  Just say the magic
>> words: "to hell with minimal state streaming parsers" or perhaps
>> something to the effect that *some* component of a layered application
>> MUST reject objects with dup names.  It's either or.  Let's choose.
>>
>> I'm happy with "some component of a layered application MUST reject
>> objects with duplicate names" -- I prefer this to the "no minimal
>> state streaming parsers" alternative.
>>
>> I will assume that in general objects rarely have lots of names, so
>> that parsers need not keep that much state in order to check for dups.
>>  Requiring parsers to reject objects with dup names is my second
>> choice.
>>
>
> Just to make sure: I also do not have any use for duplicates, and consider
> them flaws in processing. I have never used duplicates for anything, nor
> find that interesting approach.
> The only concern really is that of mandating (or not) detection and/or
> prevention at lowest level components of commonly used processing stacks
> (low-level push/pull parser, higher-level library or app code that builds
> full representations), since this is significant cost, based on extensive
> profiling I have done at this level.
>
> Case of application code directly using streaming parser/generators is not
> nearly as common as that of frameworks using them to produce higher level
> abstractions.
> These higher level abstraction (JSON tree representation, binding to
> native objects) do either report errors such as duplicates, and at very
> least can detect it and use consistent handling. They can do it much more
> efficiently than low-level components since they have to build
> representations that then serve as data structures for detecting/preventing
> duplicates.
>
> Specific concern for me is this: if specification mandates detection
> and/or prevention for parser, generators, without any mention that 'parser'
> and 'generator' are logical concepts (thing that reads JSON, thing that
> writes JSON), I will have lots of users who promptly demand low-level
> components to force checks.
> And then I get to spend lots of time discussing why such checks can (and
> IMO should) still be pushed to higher level of processing. It is amazing
> how much FUD can be generated based on cursory reading of specifications.
>
> This concern extends to suggested "Internet JSON messages" specification.
>
> I would like simple suggestion that some component of the processing
> should/must detect and report duplicates; and prevent producing of same;
> or, lengthier explanation of what "parser" and "generator" mean (parser is
> such a horrible misnomer -- there is very very little parsing involved,
> it's just a lexer, and optional object builder -- but I digress).
>
> -+ Tatu +-
>
>