> So from the point of view of e.g. GMail, it is making HTTP requests via XmlHttpRequest still is it not?
No, it's making SDPY requests. It is, however, making that difference insignificant to the application developer using the xmlHttpRequest API. HTTP is a protocol not an API. This is exactly what the paper says; the protocol is designed to make the API differences very minimal.
> And from the point of view of my Django application sitting behind some future apache/nginx SPDY module I will still be accepting HTTP requests and responding with HTTP responses will I not?
No, Django doesn't talk HTTP -- Django talks WSGI or CGI. That hides many of the details of the protocol in use -- I imagine that you could run Django with a server that sends/receives web requests over FTP. That doesn't make FTP into HTTP.
SPDY does not sit in the same level as SSL. With SSL, HTTP packets are tunneled through it. SDPY replaces HTTP; there is no fully formed HTTP message inside. If SPDY was merely multiplexing and compressing HTTP streams in frames, I would agree that it would be like HTTPS. But SPDY doesn't contain HTTP streams; it's all right there in the document.
> No, Django doesn't talk HTTP -- Django talks WSGI or CGI. That hides many of the details of the protocol in use -- I imagine that you could run Django with a server that sends/receives web requests over FTP.
I don't know how you would make e.g that[1] work on FTP. Basically you would end up encapsulating HTTP inside FTP, not using one in place of the other.
A CGI script takes raw (yet conveniently split by the web server) HTTP data from ENV vars and stdin, and outputs HTTP data directly to stdout. Django HttpRequest and HttpResponse object merely provides a convenient helper for that and does not actually abstract anything. The web server pipes the response as is straight to the client via TCP (unless there is SSL, where it will just obliviously encrypt the stream).
To comply with that, as SPDY is a replacement to HTTP, mod_spdy transcodes stuff live [2].
No, it's making SDPY requests. It is, however, making that difference insignificant to the application developer using the xmlHttpRequest API. HTTP is a protocol not an API. This is exactly what the paper says; the protocol is designed to make the API differences very minimal.
> And from the point of view of my Django application sitting behind some future apache/nginx SPDY module I will still be accepting HTTP requests and responding with HTTP responses will I not?
No, Django doesn't talk HTTP -- Django talks WSGI or CGI. That hides many of the details of the protocol in use -- I imagine that you could run Django with a server that sends/receives web requests over FTP. That doesn't make FTP into HTTP.
SPDY does not sit in the same level as SSL. With SSL, HTTP packets are tunneled through it. SDPY replaces HTTP; there is no fully formed HTTP message inside. If SPDY was merely multiplexing and compressing HTTP streams in frames, I would agree that it would be like HTTPS. But SPDY doesn't contain HTTP streams; it's all right there in the document.