[Web-SIG] Time a for JSON parser in the standard library?

[Graham Dumpleton]

On 11/03/2008, James Bennett <ubernostrum at gmail.com> wrote:
> On Mon, Mar 10, 2008 at 8:37 AM, Mark Ramm <mark.mchristensen at gmail.com> wrote:
>  >  I would definitely support the incusion of a JSON library in the
>  >  standard lib.   And, I think that it should be simplejson which is
>  >  used by TurboGears, Pylons, and bundled with Django.
>
>
> I'd tentatively agree, though I recall seeing a post not long ago
>  (which I am currently unable to find) from the author of jsonlib
>  lamenting the fact that most of the other JSON modules for Python had
>  various significant inconsistencies with the RFC. While authors of
>  competing tools should be taken with a grain of salt, I do think
>  compliance with the spec is an important factor for any particular
>  module that might be blessed with stdlib membership, and so should
>  play a bigger role in any such decision than mere benchmark speed.

The problem with the JSON 1.0 specification was that it wasn't always
as clear as could have been. As a result different server side
implementations interpreted it differently, as did the JavaScript
clients. I'll admit that it has been a while since I looked at it and
maybe things have improved, but certainly it used to be the case that
finding a JavaScript library that talked to a specific server side
implementation wasn't always easy. End result was that the JavaScript
library would often only work with the specific web framework it was
originally designed for and nothing else.

The problem areas were, different interpretations of what could be
supplied in an error response. Whether an integer, string or arbitrary
object could be supplied as the id attribute in a request. Finally,
some JavaScript clients would only work with a server side
implementation which provided introspection methods as they would
dynamically create a JavaScript proxy object based on a call of the
introspection methods.

Unfortunately the JSON 1.1 draft specification didn't necessarily make
things better. Rather than creating a proper layered specification
which separate lower level transport and encoding concerns from higher
level application concepts such as introspection they bundle it all
together. Thus they try to enforce that a server must support
introspection even though doing so may be totally impractical
depending on what the JSON server adapter is hooking in to. They also
introduced all this muck about having to support both positional and
named parameters at the same time.

As well as all that, I also recollect seeing some complaints about
servers handing character encoding wrongly. This may be the thing you
are talking about.

Thus my question is, what version of the JSON specification are you
intending to support.

Graham