- From: ??? <willchan@chromium.org>
- Date: Thu, 24 Jan 2013 09:34:26 -0800
- To: Phillip Hallam-Baker <hallam@gmail.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Greg Wilkins <gregw@intalio.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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