RE: In Defense of Header Compresson

I agree that JSON is too rich.

I completely agree that the mapping has to be static.

Henrik

From: Roberto Peon [mailto:grmocg@gmail.com]
Sent: Thursday, August 16, 2012 1:13 PM
To: Phillip Hallam-Baker
Cc: Robert Brewer; Ilya Grigorik; Henrik Frystyk Nielsen; Patrick McManus; ietf-http-wg@w3.org
Subject: 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<mailto: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<mailto:fumanchu@aminus.org>> wrote:
> Ilya Grigorik wrote:
>> > On Wed, Aug 15, 2012 at 4:36 AM, Henrik Frystyk Nielsen <henrikn@microsoft.com<mailto: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<mailto:fumanchu@aminus.org>


--
Website: http://hallambaker.com/