W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: Should Web Services be served by a different HTTP n+1?

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Thu, 24 Jan 2013 10:48:06 -0500
Message-ID: <CAMm+LwhCtd-m5uJnv+vcTTq9WcR3bEDQndV2cZqQE1ApNasCXA@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Cc: Greg Wilkins <gregw@intalio.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Thu, Jan 24, 2013 at 10:40 AM, Julian Reschke <julian.reschke@gmx.de>wrote:

> On 2013-01-24 16:20, Phillip Hallam-Baker wrote:
>
>> If people don't want there to be two different families then I think the
>> header compression needs to be totally rethunk.
>>
>> I do not want to have a compression library in my Web Services. Too much
>> code bloat and more importantly, too much memory overhead and too much
>> CPU.
>>
>> If we want to have a single protocol then maybe what we should be
>> thinking of is using the coap codes as the starting point for header
>> tokenization.
>> ...
>>
>
> As a matter of fact, figuring out the header field serialization is one of
> the current HTTP/2 related topics the WG discusses. See the various
> proposals and test suites.
>

Yes and the SDPY proposal is what prompted my proposal to split the
protocols.

SPDY is hyper optimized for Web Browsing to the total exclusion of all
other concerns. I would like a simpler mechanism for parsing headers. SPDY
is a lot more complex.

I am not very interested in the relative packing efficiency of a class of
algorithms I don't want. I don't care how many bytes the compression saves
on the wire if it requires me to pipeline my messages through a compression
library.

Anything that involves hash functions is going to be a non starter as far
as I am concerned.

-- 
Website: http://hallambaker.com/
Received on Thursday, 24 January 2013 15:48:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 24 January 2013 15:48:38 GMT