[erlang-questions] fast JSON parser in C
Serge Aleynikov
saleyn@REDACTED
Fri Jul 25 13:12:31 CEST 2008
Perhaps a little generalization would save us from having to add more
BIFs like binary_to_* and *_to_binary in the future:
proto_to_binary(Term, [{codec, Codec}]) -> binary()
binary_to_proto(Bin::binary(), [{codec, Codec}]) -> Term
Codec = json | Other
Also, this is not specific to the thread, but while on this subject, I
don't quite understand why JavaScript Object Notation (JSON) is so
heavily demanding double quoting everything in contrast to the
JavaScript Object Notation built into all browsers. What I mean is that
the javascript interpreters built into browsers happily understand this
notion of an object:
{foo: 1, bar: "value"}
or
{foo: 1, bar: 'value'}
whereas in JSON this would require to be written as:
{"foo": 1, "bar": "value"}
The first form seems more natural for an Erlang programmer, and if JSON
BIF parser is included in the OTP, perhaps a customization to support
this variant of the format would be a worthwhile addition as most
frequently JSON is used for interaction with browsers that happily
accept the first, more compact, form.
Serge
Joe Armstrong wrote:
> Since JSON seem to be ubiquitous is seems to me that there would be
> a strong case for a couple of new BIFs, term_to_json and json_to_term.
> these would work like binary_to_term and term_to_binary the difference
> being that
> instead of converting to a binary containing the external term format,
> we convert
> to a binary containing a JSON encoded string.
>
> I imaging that modeling this code on the existing term_to_binary and
> binary_to_term
> code would not be impossibly difficult (you have to make it reentrant
> and not to
> not hog the CPU for too long ... and so on ...)
>
> And yes - it is pretty horrid increasing the number of BIFs but this
> might just be
> a useful addition.
>
> This would ease seamless integration with a lot of external programs :-)
>
> /Joe Armstrong
>
> On Thu, Jul 24, 2008 at 11:02 AM, Martin Carlson
> <martin@REDACTED> wrote:
>> You might want to go with the ei interface rather than the erl_interface
>> since it is not as clumsy to use. Further, you might want to have a look
>> at the ejabberd expat driver and just replace the expat stuff with your
>> json SAX events.
>>
>> -Martin
>>
>> Chris Anderson wrote:
>>> On Wed, Jul 23, 2008 at 1:49 PM, Jonathan Gray <jlist@REDACTED> wrote:
>>>> However when I get a big chunk (around 80-120K) directly from Erlang as
>>>> binary (using term_to_binary in erlang), I'm unable to decode it using
>>>> erl_interface erl_decode, though it can be decoded fine from within Erlang.
>>> Good to know - CouchDB's Erlang -> JSON encoding is fast enough to not
>>> need help from C. I'm just working on making the JSON -> Erlang fast
>>> enough, so as long as I can get string buffers over to C in the first
>>> place, it sounds like you're not having a problem moving data from C
>>> back to Erlang.
>>>
>>> Time to buckle down and code!
>>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
More information about the erlang-questions
mailing list