Re: [hybi] SPDY protocol from google frame

[Jamie Lokier <jamie at shareable.org>]

Infinity Linden (Meadhbh Hamrick) wrote:
>    it just seems to me that we're talking about bidirectional HTTP here;
>    not BEEP or IIOP or SS7.

WebSocket is clearly part of the HyBi discussion, and WebSocket's spec
editor clearly sees uses cases which are more like the IIOP and SS7
end of things than bidirectional HTTP.

That is, very small control messages between an application and it's
server.

SO I don't think we can just casually assume we're talking about
bidirectional HTTP.

>    HTTP is generally NOT a binary protocol.

The HTTP headers and framing aren't, but the bulk of what's sent over
a HTTP connection are the bodies, which are often binary or compressed text.

>    doesn't it make sense that a bidirectional version of it should also
>    be ASCII/text based?

Probably, but there is no consensus that bidirectional HTTP is an
ideal thing to aim for.

>    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?

For applications which involve a flow of small control messages, as
envisaged by at least some WebSocket developers, each message is only
a short string and HTTP headers would take more space than the
messages themselves.  That means >50%.

I guess that's why Google use compression in SPDY :-)

Personally, when debugging HTTP used for applications tunnelling
two-way messaging over HTTP, the text HTTP headers are only so useful.
They don't even contain all the addressing information in such
applications - most of what's interesting is encoded in the message
bodies, often a proprietary protocol layered over HTTP (that being
something we can hopefully improve by standarding useful HyBi).

With such applications, it's far more useful to have a good tracing
tool that can parse the protocol(s) in use and spit out an expanded
textual representation of the relevant parts.

That applies to binary protocols too.  If you're spending too much
time looking at binary network traces and you'd prefer that it was
text for ease of debugging, perhaps what's missing is a little tool to
annotate the traces, rather than a change of protocol.

The real strength, IMHO, of text-based protocols is their potential
ease of implementation and ease of extension.  If a text-based
protocol doesn't have those qualities, the text aspect is not so useful.

-- Jamie