> On Nov 9, 2015, at 1:02 AM, Cory Benfield <c...@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
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
