There are some places around which are running out of frequency/spectrum, you are correct.<div><br></div><div>However, the advantages of binary over JSON aren't as huge as they appear on the surface.</div><div><br></div>
<div>1)  gz compression on JSON brings things down closer to hand-rolled binary protocols</div><div>2)  Application space usage (frequency of sends, streaming vs periodic updates etc)</div><div>3)  Dev time, time to market, etc.  </div>
<div>4)  Move bandwidth is becoming available (FCC here in the US, etc)</div><div>5)  4G LTE rollouts</div><div>6)  WiFi coverage expansion</div><div><br></div><div>Sometimes you have to pack it down, but for a lot of mobile uses JSON is just the right way to go (with liberal uses of -define() and an eye that you may need to swap protocols later.)</div>
<div><br></div><div>-mox</div><div><br></div><div><br><div class="gmail_quote">On Wed, Apr 11, 2012 at 11:49 PM, Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com">erlang@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Apr 12, 2012 at 6:57 AM, Mike Oxford <<a href="mailto:moxford@gmail.com">moxford@gmail.com</a>> wrote:<br>

> A truly stripped down binary-protocol can be faster and leaner than JSON,<br>
> but for web-work JSON is highly preferred.  Why?  Javascript has zero tools<br>
> for handling binary data and PHP's binary support is all but non-existent.<br>
> mochijson2 is a good library for converting between erlang terms and JSON.<br>
><br>
> JSON is more word-y and takes up more bandwidth, sure, but most people<br>
> aren't uber-optimizing for 56k modems these days (exception: mobile.)<br>
<br>
Right but "exception:mobile" is the kicker - we're running out of<br>
mobile bandwidth real fast.<br>
demand for for mobile bandwidth is growing at a faster rate than<br>
supply - and supply<br>
is limited by *physics* - as sales of smartphones increase there is<br>
more and more<br>
pressure on the net - 3G sucks in most city-centers.<br>
<br>
This means that mobile apps must "weight every byte on golden scales"<br>
<br>
JSON is *not* highly preferred here - I'd use UINT8INT arrays and<br>
huffman encoding<br>
and caching if the content is to be future proof. It's not much good<br>
making a cross platform<br>
app that just won't run in a congested mobile net ...<br>
<br>
/Joe<br>
<br>
<br>
<br>
> The ease of using JSON in Ruby + PHP + javascript + iOS + Android more than<br>
> makes up for the wire overhead.   And it's easier to read tcpdump/pcaps, use<br>
> existing tools like curl and read native traces/dumps.<br>
><br>
> If you're just using backend server-server, BERT is easier and protobufs is<br>
> smaller/more efficient.<br>
><br>
> I use JSON on the front, BERT on the back with protobufs for talking to<br>
> Riak.  I deprecated AMF and a custom binary protocol on the front due to the<br>
> above reasons.<br>
><br>
> -mox<br>
><br>
><br>
> On Wed, Apr 11, 2012 at 9:20 AM, Heinz N. Gies <<a href="mailto:heinz@licenser.net">heinz@licenser.net</a>> wrote:<br>
>><br>
>> I was thinking about the same,<br>
>> after some testing I went to use JSON it was smaller then BERT+base64 for<br>
>> my cases without it I had problems with transmissions.<br>
>><br>
>> Regards,<br>
>> Heinz<br>
>> --<br>
>> Heinz N. Gies<br>
>> <a href="mailto:heinz@licenser.net">heinz@licenser.net</a><br>
>> <a href="http://licenser.net" target="_blank">http://licenser.net</a><br>
>><br>
>> On Apr 10, 2012, at 04:26, ngocdaothanh wrote:<br>
>><br>
>> > What is the best way to use BERT encoding (<a href="http://bert-rpc.org/" target="_blank">http://bert-rpc.org/</a>) with<br>
>> > WebSocket?<br>
>> ><br>
>> > BERT is binary but WebSocket does not support binary at this moment.<br>
>> > Should I use base64 to encode BERT binary to normal string? Base64 has<br>
>> > 33% overhead (<a href="http://en.wikipedia.org/wiki/Base64" target="_blank">http://en.wikipedia.org/wiki/Base64</a>). How much space can<br>
>> > BERT save compared to JSON?<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>
>> _______________________________________________<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>
><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>
</blockquote></div><br></div>