[erlang-questions] BERT encoding and WebSocket

[Mike Oxford]

There are some places around which are running out of frequency/spectrum,
you are correct.

However, the advantages of binary over JSON aren't as huge as they appear
on the surface.

1)  gz compression on JSON brings things down closer to hand-rolled binary
protocols
2)  Application space usage (frequency of sends, streaming vs periodic
updates etc)
3)  Dev time, time to market, etc.
4)  Move bandwidth is becoming available (FCC here in the US, etc)
5)  4G LTE rollouts
6)  WiFi coverage expansion

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.)

-mox


On Wed, Apr 11, 2012 at 11:49 PM, Joe Armstrong <erlang@REDACTED> wrote:

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