[Twisted-Python] HTTP/2 and Twisted

[Glyph Lefkowitz]

> On Nov 9, 2015, at 1:02 AM, Cory Benfield <cory at lukasa.co.uk> wrote:
> 
> All,
> 
> With the work on #7860 nearly done,

_Actually_ done, now.

> Twisted should be in a good place to have a HTTP/2 implementation. There’s currently a Trac ticket (#7460) for adding HTTP/2 support to twisted.web, which is obviously a good idea. I’m happy to take on that work.

<3 <3 <3

> What I want to get a picture for is how much of the Twisted support should live in Twisted itself. Currently I’m planning to base the implementation on Hyper-h2[0]. This is because it seems totally needless to write a new HTTP/2 state machine when a perfectly good one already exists (full disclosure: I’m the maintainer of Hyper-h2).

Did somebody say STATE MACHINE??? https://github.com/glyph/automat <https://github.com/glyph/automat> (Seriously though maybe look at it, it might make some of the innards of h2 nicer, or, maybe you will have some ideas about how broken it is and could tell me them.)

Yes, we should definitely depend on h2 as a library and not do our own thing.  Frankly, Hyper-h2 is almost SURREAL in how well-factored and decoupled the implementation is from I/O.  If libraries in the Python ecosystem looked like this generally, Twisted would be a much better platform than it is.  (Frankly, most of Twisted's _own_ protocol implementations should aspire to such cleanliness.)

> However, we’ll still need a HTTP/2 Protocol, and the twisted.web integration. The twisted.web integration will definitely need to be done in Twisted, but Adi has pointed out to me that it may be better for the HTTP/2 Protocol itself to live outside of core Twisted (probably as a sub-project of Hyper, with a working title of txh2). This would give us a lot more flexibility and speed to iterate.

Creating this dependency loop (twisted->txh2->(twisted->txh2->..., h2)) seems potentially problematic, and maybe more trouble than it's worth in terms of factoring things out.  An IProtocol implementation is literally three methods - makeConnection, dataReceived, connectionLost - so if we put this together nicely there should not be too much code on the Twisted side of things.  Or at least, so I imagine; just the glue to hook it up to (sigh) IResource, et. al.

One potential way to keep the dependency graph from being cyclical is to build the interface in terms of Tubes (see <https://github.com/twisted/tubes <https://github.com/twisted/tubes>> and <https://twistedmatrix.com/trac/ticket/288 <https://twistedmatrix.com/trac/ticket/288>>) and move the Twisted-y parts of Tubes (like undefer.py) into Twisted proper.

Another would be to actually extract Deferred for real, and it seems the time is ripe for such an adventure.

> I want to get a sense of what the team believes is the best approach. Can I have your opinions? How much of this should be in Twisted itself?

Can you maybe expand a little bit on what pieces you think need to exist, in terms of what the Protocol would actually do?  Are you thinking about things like integration with Cred?

-g
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20151111/e8b8ff08/attachment-0002.html>