On 15 October 2014 10:04, Antoine Pitrou <solip...@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. With the HTTP example you gave, it looks fine, and I'm sure that equivalents can be made for websockets etc too. 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. 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. Seems to me that there are two broad directions here: we can have a WSGI-thing where it looks just a little different to WSGI, or we can have a pep-3156 Protocol interface. We can share a bunch of logic either way - e.g. CONTENT_LENGTH etc, but the mechanics of writing middleware might be quite different. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: https://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com