Contents |
The Web over PSYC
How to deploy PSYC as an optimized latency-free alternative to HTTP and as an open and more broadminded alternative to SPDY.
Request
HTTP methods shall be mapped to equivalent PSYC methods. Let's make it easy and use
- _request_get
- _request_post
- _request_put
- _request_delete
- _request_head
and so forth. We'll come up with suitable variable names and encodings for all of HTTP header fields as we need them. Soon we should also come up with compact encoding for all of the mentioned methods and variables.
Reply
The numeric return codes given in HTTP have methods as counterparts in PSYC:
- 2xx would be _status, sometimes _info or just _echo instead
- 3xx are redirects which in PSYC frequently are considered a subfamily of _failure
- 4xx are _errors
- 5xx are _failures
Upgrade
How to upgrade an existing HTTP connection to PSYC like we do with XMPP? That's a bit tricky. The browser sends us an entire HTTP request, typically a GET. It could carry an extraConnection: PSYCor
Switch: PSYCheader that declares PSYC availability to the server (much like it already does for Keep-Alive). A tag must also be specified somehow. The server would immediately send a PSYC circuit initiation instead of an HTTP protocol reply in order to perform the switch, then at any time send a PSYC-encoded reply to the original request carrying the appropriate tag. Once the browser sees the server switching to PSYC it can switch to PSYC too. Simply send a circuit initiation instead of an HTTP request, as it would do in case of keep-alive or HTTP pipelining.
What else?
This is the kind of no big deal thing that we frequently do not mention in this wiki, how to actually implement certain things in PSYC. In fact, we still leave many aspects unspecified below - all we say is, it is trivial to do when the time is ripe. All we need is a way to agree how for example Accept-Language headers are to be encoded in PSYC. _list_language seems to make sense. And so on.