Heya,
Joe Armstrong tries to get the Erlang community to agree
on a single JSON library that fits everybody's needs. The
biggest players here (according to Joe I guess) are
MochiMedia and ourselves.
Hence the dialogue I quote below:
Begin forwarded message:
From: "Joe Armstrong"
Date: July 7, 2008 10:51:07 AM GMT+02:00
To: "Jan Lehnardt" <[EMAIL PROTECTED]>
Cc: "Bob Ippolito"
Subject: cjson.erl
Hi Jan,
[CC'd to Bob Ippolito (Glad to see the facebook stuff taking off -
great work :-)) ]
I've been staring at cjson.erl ...
The comments say it's derived from mochijson.erl.
In the mochiweb there are two json representations
mochijson2.erl and mochijson.erl
I think the "2" is the better one :-)
I think it would be a good idea if you could come to some agreement
with the mochiweb people as to the best representation of
JSON terms in ERlang and both go out with a single library.
cjson.erl lacks a type declaration in the documentation - which it
needs
(reading the code is hopeless)
mochijson2.erl has this type declaration
%% @type json_string() = atom | binary()
%% @type json_number() = integer() | float()
%% @type json_array() = [json_term()]
%% @type json_object() = {struct, [{json_string(), json_term()}]}
%% @type json_term() = json_string() | json_number() | json_array() |
%% json_object()
I'm not sure about the additional "struct" tag - nor the additional
atom tag in json_string
How about ...
@type json_object = {[json_tag::binary(), json_term()]}
@type json_string() = binary()
this makes the erlang term map to JSON in an unambigous manner and
the compiler should be able to generate faster code, since
unpack(Json) when is_binary(J) -> ...
will only have disjoint branches.
I think that:
lists should *only* be used for json_arrays
binary should *only* be used for json_strings
json objs should be *only* be tuples (of pairs) {{Tag,Val},
{Tag,Val},...}
(possibly {Tag1,Val1,Tag2,Val2,....} might be better???)
I think it would be a good idea to isolate this problem - agree
(having done some
measurements, on the fastest and *prettiest* way to do this) -
jointly change
your code bases (at the same time) and then tell the world - then
issue ONE
library.
Just for fun I've downloaded the wikipedia using the ideas in
http://users.softlab.ece.ntua.gr/~ttsiod/buildWikipediaOffline.html
(I want to converts the XML representation of the wikipedia into JSON
and inject it into coutchDB
and serve it up with mochiweb - I need to write a rendering engine to
convert wiki markup to HTML
(this is said to be tricky since there is no spec :-)
This should be a good test of coutchDB and mochiweb)
Cheers
/Joe Armstrong
And Bob's reply:
From: "Bob Ippolito"
Date: July 7, 2008 6:12:32 PM GMT+02:00
To: "Joe Armstrong"
Cc: "Jan Lehnardt" <[EMAIL PROTECTED]>
Subject: Re: cjson.erl
{struct, ...} is what the library that ships with Yaws does, which is
why I used that. Using just {[{Key, Value}]} looks fine to me also and
should be do-able without breaking compatibility immediately.
The reason atoms are accepted is only for encoding purposes, not for
decoding. There is an unambiguous format from JSON -> Erlang but for
Erlang -> JSON some conveniences are allowed for practical reasons.
I'm fine with the {struct, ...} -> {...} change that Joe proposed
because I can do that in a backwards compatible way.
-bob
What is our take on this? :) Damien?
I'll forward our discussions back to Joe and Bob (in case they don't
read this list).
Cheers
Jan
