Pieter Hintjens wrote:
> Fair enough. Would it be correct to describe this as an asynchronous
> message framing protocol designed to be layered on top of HTTP?
No, because it is incompatible with HTTP.
It will not work over existing proxies, it will not work over port 80
on some parts of the existing internet, and it will not work through a
general purpose HTTP server which passes things to per-URL handlers,
like most HTTP servers do.
But those are all solvable problems :-)
> Thus, the complex one-off work (like authentication) is done using
> synchronous, pedantic HTTP while the high volume work (message
> transfer) is done using fast, asynchronous BWTP? Presumably after
> switching to BWTP, one does not return to HTTP.
>
> This is a good pattern IMO.
I agree, except by dropping HTTP entirely after the negotiation, it
does implicitly suggests you need multiple connections if the complex
things, like authentication, need to be different for separate
back-end processes.
That's probably not a common scenario, and most protocols work like
that, so that's fine. (But as an observation, when it occurs it'll be
less network-efficient than pipelined HTTP.)
Unfortunately, that prevents client implementations from automatically
sharing connections between multiple API instances. That seems to
inherit an awkward (mis-)feature of the WebSocket API: multiple
applications running side by side can either not share connections at
all, or do so by using a different API entirely ("workers"), a
situation which will discourage network efficiency.
> My proposal would be to use a wiki, where the text can be edited
> collaboratively, and where we can track issues and todos. I usually
> use wikidot.com for such things (e.g. www.restms.org). Glad to set
> that up if you need it.
Is there a system for annotating the document with comments?
-- Jamie
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.