Re: [Json] serializing sequences of JSON values

[Marc Lehmann <[e-mail]>]

On Mon, Mar 10, 2014 at 11:14:29AM -0700, Jacob Davies <[e-mail]> wrote:
> Does either the old or new specification say anything about multiple
> values in sequence? I'm pretty darn sure the old version at least said
> that application/json documents contain one and only one value, and
> says nothing about serializing JSON in other formats, so encapsulation
> is not addressed.

Keep in mind that a) JSON existed before it was an RFC and b) that the RFC
says a json document contains only one value is unrelated to this issue,
as one should be able to rely on the format specification.

As JSON is (or was...) self-delimited, and this is a common concept among
serialisation formats, it shouldn't be surprising that some people relied
on it.

> I also don't see how any process that expects to read sequences of
> self-delimited JSON objects and arrays is going to blithely accept
> numbers and strings and whatnot. I find the idea unlikely that there
> is some running code that 1. expects sequences of JSON values with
> no delimiters, 2. uses a parser that precisely followed the JSON
> specification and rejected anything but JSON objects and arrays prior to
> this change, 3. has that parser change under it to accept all kinds of
> values and 4. is so indifferent to the contents of what it is processing
> that it doesn't notice that it's getting numbers and strings instead of
> objects or arrays.

Well, the code exists (making this unlikely idea a certainty), I have
written it, and it is used, and it is in trouble now. I also don't
think it is rare, because this situation arises quite naturally in
non-monolithic designs:

   1. you have some application that exchange json texts, using
   2. a protocol that tunnels json texts, which uses
   3. some generic json coder.

neither of these might know about the other, e.g. because the json-tunnel (2
above) is used to connect applications (1 above) on different hosts for
example.

after upgrading the json coder, apps can silently exchange json texts,
and the protocol that worked fine before might silently corrupt data. and
since the json coder is often a generic component that comes with some
"framework" (likewise 2), this situation is quite likely in practise.

Even if unlikely, given the implications, the RFC should not just have
ignored this issue.

As an implementer (with JSON::XS, which so precisely followed the spec
that it found at least one bug in the official testsuite btw.), I am now
in a fairly bad situation - silently switch to the new JSON format and
push the problem to the users, or force them to enable the new version
manually. JSON::XS did support the "new JSON" format via a switch as an
extension, but applications had to explicitly ask for it, so presumably
know what they are dealing with.

Both solutions (silently switching, or defaulting to "old JSON") obviously
don't appeal to me, and having "new json" and "old json" is such a
horrible concept in itself, especially with JSON, which really shouldn't
be split into two different formats after it has been deployed to such an
extent.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      [e-mail]
      -=====/_/_//_/\_,_/ /_/\_\