- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Mon, 16 Jul 2012 15:16:02 +0000
- To: Mike Belshe <mike@belshe.com>
- cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
In message <CABaLYCswvXipBNsjFDnmEUR2AbVow6uLe+7uLJ0RD2wY_8US_w@mail.gmail.com> , Mike Belshe writes: >You've got it in your >head that a the people that started on this work are idiots and unopen to >public debate. No, I'm very impressed by what the SPDY has done, I've said so repeatedly. >Do you think the other companies - from Facebook to Twitter [...] I think they are all very big companies with world wide distribution of http-server facilities. Most websites have only one geographical location. This "we're everywhere" bias showed up in the initial release of SPDY numbers, which looked wonderful, thanks the the fact that Google has low RTT to anybody in the world, and thus could "afford" the TLS-RTT penalty, a luxury not many websites have. But my major problem with SPDY is simply that it is additive, it just adds another 50 pages of sediment to the pile of RFCs necessary to implement HTTP. SPDY does nothing to address problems like User-Agent, Cookie, ASCII representation of timestamps, it just throws it all into deflate and hopes for the best. Take the discussion going on about "non-GMT" timestamps right now as example: Resolving that is probably going to add another 20 lines of text to clarify. If HTTP/2.0 defines all timestamps as a POSIX::time_t binary timestamp, you can rip out the entire section 8 out of part2, eliminate tons of weird error-cases and their handling, and everybody in the HTTP-chain will save cpu cycles. That is the sort of improvement I expect from HTTP/1 to HTTP/2 and SPDY does not deliver it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Received on Monday, 16 July 2012 15:16:30 UTC