Separation of protocol spec

[Robert]

Hi,

SPDY itself could be reused to other protocols than HTTP. IMAP might
also benefit when the SPDY is used as the transport: parallel streams
to copy/move messages and fetch mail parts.

Wouldn't it be a good idea to split SPDY protocol spec into two specs?
One for the "raw" transport and one for http "application"?

Robert

[Mike Belshe]

I'm not opposed to it; but I would like to keep us focused on HTTP.  I fear adding a generic requirement will simply distract us from our primary goal.

Mike

[Witold Baryluk]

2009/11/24 Mike Belshe <mbe...@google.com>:

> I'm not opposed to it; but I would like to keep us focused on HTTP.  I fear
> adding a generic requirement will simply distract us from our primary goal.

I agree. If one will want to reimplement some other protocol, like IMAP,
to work in SPDY like way, it will anyway take considerable
time and amount of work. I think it will be better to map IMAP
to HTTP then, so it will JUST work with SPDY.

What others protocols can bennefit from SPDY?
I can't find any real candidates. It is better to redesign
particular protocol to work in better way, than
map it to generic (not optimal for this application) SPDY.

[Mark Nottingham]

Yes. More than anything, I think that's what happened to BEEP.

--
Mark Nottingham http://www.mnot.net/

[James A. Morrison]

At some point, I'll probably write up a document about writing a proxy
that converts from http to spdy, which will probably be the closest
thing we have to a separation of spdy and http in spdy for a while.

2009/11/24 Robert <robert...@googlemail.com>:

--
Thanks,
Jim
http://phython.blogspot.com