|
It was interesting to hear the IAB opinions on this in relation
to internationalization. The thesis was that the bulk of the web is video or
some other efficiently encoded binary data and that text makes up a very small
proportion of the data that is moved around. The purported costs of more
verbose encodings (in this case of Unicode) were actually considered negligible
when compared to the other benefits. Thus, I’d question whether these speed benefits are of any
tangible benefit. Sure, we minify _javascript_ and there are still bandwidth-limited
devices that would benefit from some speed improvement, but I don’t see a
binary protocol improving this situation significantly. And when I consider
that some folks are getting better bandwidth on their mobiles than I get over
my ADSL2+ connection at home, I wonder why we waste so much time on saving
bits. Can anyone point to the studies on impact of HTTP header sizes
on throughput, latency and overall bandwidth use? I’m also increasingly of the view that channels-based protocols
aren’t necessarily the right way to solve head-of-line blocking problems. There
are other methods that do not demand the same overheads. For instance, a
simple request identifier can be used for request-response correlation. I’m actually more excited about the prospect of getting HTTP
over SCTP. --Martin From: hybi-bounces at ietf.org
[mailto:hybi-bounces at ietf.org] On Behalf Of Ian Fette (????????) The point of SPDY was to make
the web faster. Billions of users requesting pages, want to speed it up. Of
those billions of users, perhaps 100 care whether it's binary or ASCII. Using
ASCII just so that it's easier for 100 people to look at the traffic on the
wire without any "specialized tools" while slowing it down for
billions of users seems like a strange tradeoff. 2009/11/12 Infinity Linden (Meadhbh Hamrick) <infinity at lindenlab.com> +1 ted i have to admit i'm a fan of text based protocols that use
ASCII for headers, allow arbitrary length fields, and whose elements are
delimited by ASCII characters. in the early days of my career, i was a fan of
fixed length fields with binary elements. to be sure, there are definitely
places where they are useful. but in my experience, when you're building
something new, the benefits of extensibility and debuggability outweigh the
drawbacks of dealing with larger, variable length messages that may require a little
bit more coding to parse. <soapbox> but i am kind of curious.. if there are people on this list
that prefer binary formats, i wonder, what are the characteristics you're
trying to preserve? a. messages should be easy to parse? b. messages and message elements should be as small as
possible? c. something else? the reason i ask it that i've had experience with building
IIOP and SS7 implementations and debugging HTTP is waay more fun than IIOP. and
by "fun" i mean that i'm less likely to drink heavily after a 24 hour
debugging session. that being said... if i was building something for the telco
ecosystem, and i needed to respond to messages in a small, deterministic amount
of time, i would be interested in investigating where i would need to use fixed
length fields in a binary message. (but i wouldn't like it.) it just seems to me that we're talking about bidirectional
HTTP here; not BEEP or IIOP or SS7. HTTP is generally NOT a binary protocol.
doesn't it make sense that a bidirectional version of it should also be
ASCII/text based? you're going to have developers and tool chains that are
probably going to assume that headers flowing across port 80 will be human
comprehensible. and while i have no problem using binary encoding when it's needed...
but... is it really needed here? do we really have use cases where the < 1% savings you
get on message size by adding binary headers and protocol flow markers makes or
breaks a service? </soapbox> -cheers -meadhbh --
On Thu, Nov 12, 2009 at 16:25, Ted Goddard <ted.goddard at icesoft.com>
wrote:
Lloyd Wood wrote: How does this compare to BEEP?
On 12 Nov 2009, at 22:05, Greg
Wilkins wrote: FYI Google have announced some work they are doing on a HTTP
improvement
|
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.