> On 12 Nov 2015, at 06:04, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote: > 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.
I think if we took this approach txh2 would be an optional dependency for Twisted, not a hard dependency. That avoids the loop, at the cost of meaning that a default naive Twisted install will have no H2 support. >> 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? Sure. What concerns me as an outsider to Twisted is where exactly there are bits of Twisted that “know” about HTTP, which bits need updating, and how to do it. If we restrain ourselves to twisted.web, this gets a bit easier, but twisted.web is still a substantial chunk of code. We *might* be able to get away with simply having classes that implement the interfaces of twisted.web.http.HTTPClient, twisted.web.http.HTTPChannel, and twisted.web._newclient.HTTPParser. These interfaces are currently implicit, but I’d probably aim to make them explicit (or as explicit as possible) for the purposes of this work so that we could in principle do a similar extension in future. However, this may not work: in particular, some of the other classes in twisted.web may know altogether too much about HTTP/1.X: in particular, if they have the nerve to write directly to a transport we’ve got a real problem with this approach, as HTTP/2 does not allow naked writes on its sockets (all data is framed). The other bit of work is that we need to update twisted.web factories to make sure that they build the appropriate protocol and can switch them as needed. Probably this means we just need a layer of indirection, but I’ve not yet worked out how this is going to work. The question becomes, given how much twisted.web will need to change to accept this H2 protocol, whether there is any advantage in having it out of tree. There’s also a question about Twisted policy: how much stuff should actually be directly in Twisted? Cory
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
