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: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 24 Jan 2013 16:55:04 +0100
Message-ID: <51015958.5080807@gmx.de>
To: Phillip Hallam-Baker <hallam@gmail.com>
CC: Greg Wilkins <gregw@intalio.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On 2013-01-24 16:48, Phillip Hallam-Baker wrote:
> On Thu, Jan 24, 2013 at 10:40 AM, Julian Reschke <julian.reschke@gmx.de
> <mailto: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.

SPDY is being used as input for the design of HTTP/2.0. One part that 
*will* be different is the header field format.

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

Then I would recommend that you participate in the discussion about that 
format; that's why we're having it.

Best regards, Julian
Received on Thursday, 24 January 2013 15:55:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:09 UTC