Re: In Defense of Header Compresson

JSON is far more rich than we need.
name-value is really sufficient for anything the protocol should
contemplate.
I'm all for tokenization, btw, so long as the mapping for tokenization is
static for long periods of time (months/years)
-=R

On Thu, Aug 16, 2012 at 8:24 AM, Phillip Hallam-Baker <hallam@gmail.com>wrote:

> What really matters for performance is the number of packets rather
> than packet size. If you are worried about the packet size then you
> should not expect a general purpose transport to meet your needs. UDP
> is going to be better.
>
> Similarly, if you are using JSON then the JSON bloat is going to be a
> lot more overhead than HTTP bloat.
>
>
> I like tokenization as a strategy as the same approach can be used for
> both the JSON and the HTTP space saving. It also means that embedded
> devices can even use the tokenized form as a replacement for header
> and JSON syntax and only use one parser.
>
> I don't see much advantage to compression for small message sizes
> unless you can avoid transporting the compression dictionary which is
> exactly what tokenization does, only with a slight reduction in
> maximum efficiency and a huge reduction in complexity.
>
> On Thu, Aug 16, 2012 at 10:36 AM, Robert Brewer <fumanchu@aminus.org>
> wrote:
> > Ilya Grigorik wrote:
> >> > On Wed, Aug 15, 2012 at 4:36 AM, Henrik Frystyk Nielsen <
> henrikn@microsoft.com> wrote:
> >> > I completely agree that if you have very small entity bodies
> >> > then maturally the header size will matter getting more
> >> > requests into the pipe faster. However, in the tests that we
> >> > have done with actual data the size of the entity bodies was
> >> > large enough that the impact was minimal. This is especially
> >> > the case if you also do bundling/minification as it naturally
> >> > leads you to large entities.
> >>
> >> It's worth keeping in mind that we're seeing more and more web
> >> "applications", as opposed to pages. Frameworks like backbone,
> >> angular, etc, all frequently make very small (usually JSON
> >> encoded) requests to indicates record updates, or to pull
> >> specific objects on demand, from an HTTP endpoint.. All of that
> >> to say: many of these requests are just a few hundred bytes.
> >> Your typical CRUD operations are all great examples: a lotta
> >> headers for a tiny payload and a 204 response. The overhead
> >> there is huge, which is why we're seeing people starting to
> >> invent their own protocols. e.g. SwaggerRocket:
> >>
> http://blog.wordnik.com/introducing-swaggersocket-a-rest-over-websocket-protocol
> >>
> >> They shouldn't have to do this...
> >
> > They shouldn't have to invent their own protocols because there are
> already plenty of protocols optimized for small-grained messages. That
> doesn't mean HTTP, which is one of the few protocols which is optimized for
> large-grained messages (in order to trade efficiency for scalability), has
> to change to become one of them.
> >
> >
> > Robert Brewer
> > fumanchu@aminus.org
>
>
>
> --
> Website: http://hallambaker.com/
>
>