[Twisted-Python] Interacting plugins and mktap --append
Hi gang, I'd like to have some interaction between 2 plugins, and I'm wondering what's the most "archtecturally sound" way of implementing that in the context of twistd/mktap. Basically, I want to do mktap foo mktap --append=foo.tap blarg and have blarg somehow obtain a reference to foo so it can call foo's methods. In my particular case, I have a MultiService in foo that I'd like to add a blarg service to, and also register some blarg stuff with one of the foo MultiService's child Services. Cheers, Steve
On Wed, 2004-05-19 at 13:08, Stephen C. Waterbury wrote:
I'd like to have some interaction between 2 plugins, and I'm wondering what's the most "archtecturally sound" way of implementing that in the context of twistd/mktap.
Short answer is that mktap isn't the right tool for this sort of thing. The long answer probably involves Glyph writing a really long email so I'll let him do that. -- Itamar Shtull-Trauring http://itamarst.org
Itamar Shtull-Trauring wrote:
On Wed, 2004-05-19 at 13:08, Stephen C. Waterbury wrote:
I'd like to have some interaction between 2 plugins, and I'm wondering what's the most "archtecturally sound" way of implementing that in the context of twistd/mktap.
Short answer is that mktap isn't the right tool for this sort of thing.
The long answer probably involves Glyph writing a really long email so I'll let him do that.
Thanks for the quick reply, Itamar! I'll do a q'n'd while I await Glyph's treatise. :)
Stephen C. Waterbury wrote:
Itamar Shtull-Trauring wrote:
On Wed, 2004-05-19 at 13:08, Stephen C. Waterbury wrote:
I'd like to have some interaction between 2 plugins, and I'm wondering what's the most "archtecturally sound" way of implementing that in the context of twistd/mktap.
Short answer is that mktap isn't the right tool for this sort of thing. The long answer probably involves Glyph writing a really long email so I'll let him do that.
Thanks for the quick reply, Itamar! I'll do a q'n'd while I await Glyph's treatise. :)
Actually, thinking about it some more, I don't know why I had locked onto the idea of using mktap that way. I'm thinking now it would make more sense to include extension packages, additional services, etc. using configuration options in footap.py. So just use one plugin and make it very configurable. ;)
On Wed, 2004-05-19 at 14:33, Stephen C. Waterbury wrote:
Actually, thinking about it some more, I don't know why I had locked onto the idea of using mktap that way. I'm thinking now it would make more sense to include extension packages, additional services, etc. using configuration options in footap.py. So just use one plugin and make it very configurable. ;)
I don't have time for the treatise at the moment, so I'll be brief :). We're wrestling with a similar issue in Quotient right now, and twisted's configuration infrastructure just isn't up to the task. The suggested work-around, effectively, is to build an easy-to-read configuration minilanguage for your .tac, hopefully one that only involves one or two python functions. (I don't mean "parse a config file", I mean, "use some tiny subset of python to configure your application".) In the large, this has problems, because different applications can't easily be configured to work with each other without significant plumbing work. This is in particular unpleasant for web apps. However, there are larger problems for us to attack, such as developing some kind of general shell infrastructure to allow people to log in over multiple protocols which potentially access different applications through the same objects... So, in short, look in quotient/deployment.py and doc/sample.tac in the _latest, brand-new release of Quotient_, 0.9.0, and there is an example you can draw from. In the future, we will try to generalize this approach and separate port-binding configuration from application configuration. Almost everything in Quotient - and anything in a well-behaved Twisted app these days - is based off of some kind of connection to storage, whether it's a pickle, a SQL database, or something weird like Atop, and a Realm which wraps that storage. Once you're past the realm, almost every protocol-level configuration option is beyond the scope of your application. The main thing that needs to be done is normalize how protocols and factories find out about the realm, and to develop an API to reliably, safely, and deterministically start up and shut down storage. This is do-able using the existing twisted.application stuff but there needs to be a higher level convenience layer built. And really, I'm not going to write that treatise, so I'll stop now ;-)
participants (3)
-
Glyph Lefkowitz
-
Itamar Shtull-Trauring
-
Stephen C. Waterbury