Thinking about how to handle protocols directly

[zostay]

One thing I've been wondering about while considering how to implement the first Smack protocol handling bits is how new protocols could be implemented in a generic way. Any protocol that is initiated by an Upgrade is pretty easy. However, some protocols, e.g., HTTP/2, might be started immediately by sending a connection preface that is identifiably separate from HTTP/1.1.

I just had this really crazy idea. What if, instead of a server handing the application an environment after parsing the header, it just handed the application the environment immediately. All the header bits are blank because the headers are not read, the application must read them instead.

Then, middleware (or the application if that's how the user rolls) can read the input stream and handle the protocol details as required. Standard middleware could be provided for handling things like SSL, HTTP/1.1, HTTP/2, WebSocket, etc. Anyone can fork or reimplement the middleware to optimize and what-not.

Where this breaks down, of course, is in handling things like CGI where the application is not actually sent the headers except by environment. In which case, CGI requires both a server implementation and a protocol implementation that knows where to find the headers.

I think there's some potential here, but I need look through all the PSGI server implementations I can find to consider the consequences of this.

[zostay]

In my latest 0.7.Draft, I have added the notion of a response protocol, which I like quite a bit. So far I've only introduced "HTTP" and "WebSocket" as protocols (which will probably be renamed to something more convenient), but I am strongly considering a "Raw" protocol, which will work something like WebSocket but with the assumption that the server will frame nothing and just give the application access to the connection. I believe I can pair this with the registration routine (see #34) and eliminate the p6wx.io extension entirely.

[zostay]

I have added this into Section 4 of the spec right now, but there are lots of unresolved questions.

• How does the application server decide which protocol to use when multiple apply?
• How does this impact how middleware works, especially in light of #34?
• Are each of these protocols defined correctly?
• Is the documentation in Section 4 sensible?

[zostay]

I have heavily revised section 4 in 52064e23cd65f41a38aa8ca51fc472ffd8cf5fac and related bits in the environment. In particular, the spec now highlights the difference between the network protocol (e.g., HTTP or WebSocket) and the application protocol (e.g., request-response and framed-socket). This opens up the possibility of implementing other protocols like an MQ or XMPP or something while reusing the framed-socket protocol (probably with some modification to facilitate message formatting and what-not, but otherwise keeping with the spirit of a framed-socket protocol). I probably still need to refine some of the details here, but I'm pretty happy with this revision.