[Web-SIG] WSGI and asyncio (tulip)?

[Antoine Pitrou]

On Wed, 15 Oct 2014 10:48:37 +1300
Robert Collins
<robertc at robertcollins.net> wrote:
> On 15 October 2014 10:04, Antoine Pitrou <solipsis at pitrou.net> wrote:
> ...
> > (that's for the HTTP part; a websockets layer would probably implement
> > a separate transport and accept a separate protocol factory; actually,
> > it could be implemented as a protocol that would parse the websockets
> > protocol and provide its own transport on top of that... there may
> > already be such a thing on the Internet :-))
> 
> So thats the bit that I'm having conceptual trouble with - servers may
> well implement the framing (and I rather think that they have to do so
> in some deployments), so we need to make sure that we don't do that in
> this context - we're behind an abstraction.

If the new WSGI specifies that the server implements websocket support,
then indeed the application shouldn't redo it.

> The question in mind is whether that is amenable to the same
> unification and layering that WSGI brought to the HTTP synchronous
> case. It looks like you'd make a protocol factory decorator.

I'm not sure why you would need a decorator. In the PEP 3156 mindset, a
protocol factory can be any 0-argument Python callable: a class, a
closure, a bound method, a global function, etc. Just pass that object
it to the server when asking it to listen (or when it tells you it
wants to listen, which is the WSGI approach AFAIU).

> Will it
> be sufficiently flexible and interoperable to be something that
> becomes a lingua franca? I don't know pep-3156 well enough to judge
> that myself.

Yes, it should. That's the formalism already adopted for serving stuff
on listening connections, e.g. (from PEP 3156):

"""create_server(protocol_factory, host, port, <options>). Enters a
serving loop that accepts connections. [...]

Each time a connection is accepted, protocol_factory is called without
arguments(**) to create a Protocol, a bidirectional stream Transport is
created to represent the network side of the connection, and the two
are tied together by calling protocol.connection_made(transport)."""

Regards

Antoine.