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

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