<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 14, 2014 at 9:38 AM, Pieter Hintjens <span dir="ltr"><<a href="mailto:ph@imatix.com" target="_blank">ph@imatix.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">When you judge an encoding like JSON you're weighing simplicity of use<br>
against efficiency. For messages you send a few times a second, at<br>
most, text encoding costs are irrelevant. The big advantage of JSON,<br>
like XML and YAML, is the ability to extend contracts experimentally<br>
and cheaply. In comparison, any binary format raises steep costs for<br>
change, creating absurd incompatibility that has no benefit. The<br>
OpenStack RPC API being a good example of this.<br>
<br>
One answer I've used with success is the "Cheap and Nasty" pattern,<br>
where slow-changing high-volume data uses a binary encoding, and<br>
fast-changing low-volume data uses JSON, XML, or similar. By forcing<br>
protocols into these extremes you can win both games. Using a single<br>
approach for the two cases creates mediocrity, in my experience. Thus<br>
mspack, protobufs, etc. are poor choices either way.<br></blockquote><div><br></div><div><br></div><div>Good point.</div><div><br></div><div>I think people "understand" JSON on two levels - at one level of understanding</div>
<div>JSON is "easy" - in this mindset encodings etc. multiple keys etc are irrelevant.</div><div><br></div><div>To an implementor of a library JSON is complicated. </div><div>When I think of *implementing* JSON<->Erlang maps My hair goes even greyer.</div>
<div><br></div><div>I think:</div><div><br></div><div> 1) does a floating point number survive a round-trip from erlang -> JSON -> Erlang</div><div> is it "bit identical" after the round trip? - why does this matter? - well it</div>
<div> might just matter - I might want to cache the result or compute a SHA1 from it.</div><div> 2) Do I have to worry about filling the erlang atom table?</div><div> 3) Do I have to handle "infinite"JSON streams (for some meaning of "infinite")</div>
<div> 4) Do want parse trees, or a SAX like interface</div><div> 5) Do I want pure erlang or a NIF (the NIF might crash erlang)</div><div><br></div><div>Now suppose there are two answers to each question. That's 2^5 implementations.</div>
<div><br></div><div>That's why there are multiple libraries - they make different design choices. </div><div><br></div><div>It's also extremely confusing to a beginner since the different design choices</div><div>
are not clearly stated - I find the choice of libraries difficult for just this reason,</div><div>they all appear to do the same thing.</div><div><br></div><div>A user of a JSON library would by now be crying out loud - "just give me</div>
<div>a ****ing library - all I want to do is parse this JSON that I have in a file.</div><div><br></div><div>This is what most libraries do - they work 99% of the time.</div><div><br></div><div>(( the 99% is horrible - just when I think a library is great I find - *but I can't do X* then</div>
<div> I'm in trouble - but I guess this is in the nature of the beast - only pure mathematical</div><div> functions have the kind of "platonic interfaces" that will never change - real</div><div> world problems with time and space involved are just plain messy ))</div>
<div><br></div><div>If we freeze the JSON design and say:</div><div><br></div><div> 1) floating point number will not survive a round-trip</div><div> 2) JSON tags will be erlang atoms</div><div> 3) Terms are not-infinite and rather small (few MB at max)</div>
<div> 4) we want a parse tree</div><div> 5) best effort at sorting out character set encodings</div><div> 6) Pure erlang</div><div><br></div><div>Then the problem becomes "easy" and can be knocked out in a few lies of code</div>
<div>using maps:from_list and maps:to_list.</div><div><br></div><div>And *because* it's easy nobody writes a library to do this.</div><div><br></div><div>The trouble is a beginner probably does not find this easy and would appreciate</div>
<div>a library that worked 99% of the time on simple problems.</div><div><br></div><div>I watched DaveTomas and Jose Valim's Erlang factory lecture where</div><div>they criticised Erlang for not having simple ways of doing common things.</div>
<div><br></div><div>I think they were right.</div><div><br></div><div>I think we to make some simple ways to solve common problems. </div><div><br></div><div>The problem is simple things are very difficult to invent.</div>
<div><br></div><div>I think we need a "otp subset" and "library subset" that is designed for beginners.</div><div><br></div><div><br></div><div>Cheers</div><div><br></div><div>/Joe</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What this comes to is, often, a protocol message split into binary<br>
fields that are extremely tuned and fast to parse, plus optionally, an<br>
extensible hash or JSON document or similar.<br>
<br>
We've built a toolkit for this, zeromq/zproto, which is simple and efficient.<br>
<br>
Loic is right that lack of URLs in JSON makes it harder to use for<br>
RESTful work, however that's trivially solved by defining URLs<br>
explicitly. Then you can do very nice RESTful work without caring what<br>
encoding you use.<br>
<br>
E.g. <a href="https://github.com/UnifyProject/RFC/blob/master/draft/rfc-2.md" target="_blank">https://github.com/UnifyProject/RFC/blob/master/draft/rfc-2.md</a><br>
<br>
tl;dr use the best tool for the job, no single encoding can solve all use cases.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Pieter<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
On Fri, Mar 14, 2014 at 8:56 AM, Benoit Chesneau <<a href="mailto:bchesneau@gmail.com">bchesneau@gmail.com</a>> wrote:<br>
> So I am curious in what could replace json today as an interoperable<br>
> exchange data format. Message pack is interesting but not sure it's a<br>
> good one (no type support). Any idea?<br>
><br>
> - benoit<br>
><br>
> On Fri, Mar 14, 2014 at 12:57 AM, Anthony Ramine <<a href="mailto:n.oxyde@gmail.com">n.oxyde@gmail.com</a>> wrote:<br>
>> Where is the scientific study that proves this?<br>
>><br>
>> Or is that just your personal experience?<br>
>><br>
>> --<br>
>> Anthony Ramine<br>
>><br>
>> Le 13 mars 2014 à 21:16, Carsten Bormann <<a href="mailto:cabo@tzi.org">cabo@tzi.org</a>> a écrit :<br>
>><br>
>>> On 10 Mar 2014, at 15:54, Loïc Hoguin <<a href="mailto:essen@ninenines.eu">essen@ninenines.eu</a>> wrote:<br>
>>><br>
>>>> Could you elaborate on what the dominant usage of JSON is?<br>
>>><br>
>>> Certainly.<br>
>>><br>
>>> JSON is used for data interchange between applications or within components of an application.<br>
>>><br>
>>> The most extensive use is from JavaScript-based Web application front-ends (running in the browser) to their backends (running on a server) and back; these are shipped as application/json representations in AJAX accesses (HTTP access from JavaScript via the confusingly named XMLHttpRequest object).<br>
>>><br>
>>> Many Web APIs that have been designed in the last half decade are described in JSON form, so applications that access another application via a Web API are likely to ship back and forth application/json representations via HTTP accesses.<br>
>>><br>
>>> Grüße, Carsten<br>
>>><br>
>><br>
>> _______________________________________________<br>
>> erlang-questions mailing list<br>
>> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
>> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
> _______________________________________________<br>
> erlang-questions mailing list<br>
> <a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
> <a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div></div>