Re: [Json] Proposed rechartering for the JSON WG

[Phillip Hallam-Baker <[e-mail]>]

On Mon, Feb 10, 2014 at 12:43 PM, Nico Williams <[e-mail]>wrote:

> On Sat, Feb 8, 2014 at 5:52 PM, Tim Bray <[e-mail]> wrote:
> > On Sat, Feb 8, 2014 at 2:50 PM, Nico Williams <[e-mail]>
> wrote:
> >>
> >>
> >> An XPath/XSLT for JSON would be good.  There's a great candidate for
> >> that: http://stedolan.github.io/jq .
> >
> >
> > jq seems like overkill. Wow, would it ever be easy to do a JSON path
> > selector.   They practically read themselves
> >
> > "buffer"/"size"
>
> FYI:
>
> .buffer.size
>
> > //"size"
>
> recurse(.[]).size
>
> > //"buffers"/./"size"
>
> recurse(.[]).buffers[].size
>
> > //"buffers"/0/"size"
>
> recurse(.[]).buffers[0].size
>
> The .name syntax is a bit to type-strong and so you get spurious error
> messages (safely ignored).  I think the right thing to do here is to
> make .name act like 'empty' when . is not an object, or if name is an
> integer, when . is not an array (but .[number] needs to continue to
> produce warnings if . is not an array).  That and add ..name syntax,
> then '..buffers.0.size' should do what you want without spurious error
> messages.  I'll defer to Stephen either way.
>
> BTW, I've needed // in XPath very often.  But I've never needed it
> when dealing with JSON data.  The JSON data I've dealt with never had
> more than one layer of structure repetition, while XML data I've dealt
> with had many.
>
> > //"buffers"/-1/.
>
> This one's a pain as jq doesn't do negative indices, so you have -1 the
> length.
>
> > "buffer"/./"key"
>


One area I would very much like to standardize on is limits like the above.
I write my code so that the decoder can cope with messages of any size and
arbitrary depth, up to the maximum that the machine can take. But that is
obviously neither needed nor acceptable for a production machine.

Someone writing a JSON spec should specify what their limits are so that a
parser implementation can reject DoS attacks early and block future
requests from that IP.

It is also an efficiency consideration in C. If I know that no request will
ever be more than 64KB long or be nested more than 10 deep, I can
pre-allocate all the necessary structures along with the socket and they
can be cleared and reused or freed as one unit depending on the load of the
server at the time. Avoiding multiple malloc calls is a good way to make a
server fly.


-- 
Website: http://hallambaker.com/