[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [hybi] SPDY protocol from google frame



+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

--
  infinity linden (aka meadhbh hamrick)  *  it's pronounced "maeve"
        http://wiki.secondlife.com/wiki/User:Infinity_Linden


On Thu, Nov 12, 2009 at 16:25, Ted Goddard <ted.goddard at icesoft.com> wrote:

It appears to be a binary framing protocol carrying
an HTTP subset.  The goals of the protocol match the
BWTP "manifesto", so hopefully the SPDY authors will
join this BOF.

I still like the idea of text-based framing and metadata
because it's easy to debug with telnet and tcpdump.
For instance, BWTP header persistence is still human
readable, would be very effective in terms of
compression, and could be retrofitted for httpbis;
whereas SPDY headers are compressed with gzip, resulting
in effective compression but no savings in header
encoding and decoding, and a random looking byte stream
unless you have a specialized debug tool.

It would be interesting to take a poll to see if people
have a binary or a text-based protocol in mind.

Ted.



On 2009-11-12, at 4:24 PM, Greg Wilkins wrote:

Lloyd Wood wrote:
How does this compare to BEEP?

From my quick look:

+ It's simpler than beep in channel management
+ It's addresses the header compactness issues
+ It is definitely bound to uber-http semantics, while beep is more general
 purpose (but could have a http binding defined).

But in concept, it is not too far apart.  It's using the same grab
bag of techniques (multiplexed channels with fragmentation and orderly
channel management) that Beep uses (and BWTP is advocating).

cheers



On 12 Nov 2009, at 22:05, Greg Wilkins wrote:

FYI Google have announced some work they are doing on a HTTP improvement

http://dev.chromium.org/spdy/spdy-whitepaper


It appears to capture many of the same ideas I was attempting to with BWTP - but
they are binary encoded and have working code :)

cheers
_______________________________________________
hybi mailing list
hybi at ietf.org
https://www.ietf.org/mailman/listinfo/hybi

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood at surrey.ac.uk>







_______________________________________________
hybi mailing list
hybi at ietf.org
https://www.ietf.org/mailman/listinfo/hybi


_______________________________________________
hybi mailing list
hybi at ietf.org
https://www.ietf.org/mailman/listinfo/hybi


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.