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

I think SPDY is simpler for parsing headers in comparison to HTTP/1
except for the compression part. Would you agree? Patrick has written
up a good comparison here:
http://blog.jgc.org/2012/12/speeding-up-http-with-minimal-protocol.html#c5703739431744738432.

Can you clarify what exactly bothers you about piping your messages
through a compression library? There are clearly some concerns, but I
want to hear what specifically bothers you.

On Thu, Jan 24, 2013 at 7:48 AM, Phillip Hallam-Baker <hallam@gmail.com> wrote:
>
>
> 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 17:34:59 UTC