[Twisted-Python] application

Antony Kummel antonykummel at yahoo.com
Mon Sep 5 09:37:29 EDT 2005


I am beginning to use twisted.application, mktap and
twistd in my project, and I have some questions about
their use:

1. It seems that mktap is aimed primarily to create
applications containing just one service (since to
append a service to an application you need a separate
invocation of mktap). I am thinking to use it mostly
to combine services and I wonder if I'm
misunderstanding something or if I should use
MultiService or what.

Specifically, I want to have numerous services that
are (modified) PB client/servers, and when several
such services are at the same process, I want them all
to use the same ServerFactory. What I did was to make
one mktap plugin for the "base server", and several
plugins for the services themselves. These services
require that the application also contains a "base
server", and they bind to it automatically. This
requires creating an application with only the "base
server", and then adding to it the different
subsidiary services. Any ideas on how to do this

2. Tap conventions: it is not very clear how to make
the best use of mktap in terms of code organization.
It seems that to make plugins I need to have a
twisted/plugins folder in my application's root
directory. In twisted, this folder contains files
named twisted_*.py, I'm not sure why this naming
convention. The files in this directory point to tap
construction modules. These modules seem to be either
in twisted/tap or in twisted/*something*, in which
case they are called either tap.py or
*something*_tap.py. Additionally, the services these
modules use come from a variety of places in which I
couldn't find coherence.

So, my question is, where should I put the mktap
plugins, the tap construction modules, and the service
implementations so that it makes sense? Am I missing

2. I understand that application is meant to hold the
services' configuration. However, there are many kinds
of configurations, and I'm struggling to make a
distinction between options that are suitable for the
mktap command line, for xml-serialized applications,
and for other mechanisms, such as a human-readable
configuration file suitable for an innocent end-user.
For example, an ini file could be used to specify the
skin of a GUI application, and debugging options, but
what is more suitable for the mktap command line?
Maybe only options that somehow affect the basic
"type" of the service?


Antony Kummel

Click here to donate to the Hurricane Katrina relief effort.

More information about the Twisted-Python mailing list