[Twisted-Python] Interacting plugins and mktap --append

[Glyph Lefkowitz]

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 ;-)