(disclaimer: this is after several hours on an aeroplane, this may all be nonsense)
So, I'm currently looking into adding some features to twisted.web -- something that historically hasn't had the best support for pluggable reactors, and which requires levels and levels of monkeypatching (see the top level of https://github.com/twisted/twisted/compare/trunk...deferreds-in-resrender-3711 ). So, I was thinking, what if we made a new way for things to get their reactor, rather than extending all these concrete implementations everywhere? Currently, you'd pass a reactor instance through to protocols by making the factory understand it, and the protocol calling self.factory._reactor or whatever. I never thought this was a supremely helpful or useful interface -- especially for one-shot classes -- so what if instead we made a new IProtocol-extending interface, which signals to tcp.Port/etc that the protocol, once created, should have a reactor set on it (maybe through some "setConnectingReactor" or something). This would mean that the factory doesn't know about the reactor in most cases (with things like HTTPFactory doing logging as an exception) -- but we could also have an IClient/ServerFactoryWithReactor, that Endpoints (which needs to know about the reactor, and which reactor it is listening on) can then check for and call a similar function, telling the Factory what reactor it is actually running under. This, I think, would reduce a bunch of duplicate code in __init__s of factories, and could be implemented in the base class of Protocol or ServerFactory, possibly. What do people think? - Amber
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
