I suppose, as the man who foisted TAPs on the world, I should answer for my
sins, or at least explain them. I still feel bad about TAPs in general,
because they're not nearly as good as they could have been, but I still feel
strongly that they're better than nothing.
On Tue, 11 Feb 2003 03:09:05 -0500, Bob Ippolito <bob at redivi.com> wrote:
> taps are to simplify running daemons. you don't need them for anything.
TAPs are for lots of things: simplifying running daemons is the most trivial
example. Even when the documentation was a lot worse, there is a good reason
that a lot of the examples describe starting with a TAP or outputting an
Application object manually.
Twisted is a very large and very featureful framework that has tried to
simultaneously provide tons of functionality for developers but still remain
user-focused. Pretty much everyone involved in the core design aspect of TAPs
feels that they're sub-optimal, so you don't see much effective advocacy of
their use.
More to the point, to paraphrase PaulT from this article:
http://www.pault.com/pault/zope/zope.html
"Even really bad integration is better than no integration." TAPs are really
bad integration. The worst thing about them is that there are places, such as
GUI clients, where they really can't apply (and thus we revert to 'no
integration').
However, TAPs at least produce an artifact that a user can understand, on some
level. A file that contains a collection of "server" objects. Some tools
exist (such as mktap --append) to manipulate that artifact, and it may itself
respond (if manhole is installed in it) to various kinds of manipulation.
These kinds of tools are the things that you don't notice very often as a
developer, as they come "for free" for doing things a certain way. For
example, most GTK or MacOS X developers are unaware that emacs keybindings are
set by default, but they use the toolkit and they don't re-bind all the keys
immediately.
Certain apps that have to play by their own rules break things. For instance,
Mozilla _does_ rebind all keys immediately, and you can tell, because their
emacs keys emulation used to be far less consistent, especially across
platforms. There are a lot of users who don't care about this, and probably
most developers don't either. When you put all the users who use all the weird
features together, though, you end up with almost everybody.
The same is true of most Twisted users, I would imagine: most people don't
invoke Manhole, or run with a wacky reactor, view the full mktap --help listing
and read all the available plugins, or append multiple services to one .tap
file. However, the ability to do all of these things with (relative) ease is
collectively important. As time goes on, we have been very slowly adding new
features and options that you can apply to any properly-built .tap.
There are a lot of reasons to use TAPs. This is similar to the
embedding-vs-extending discussion, where I have made my opinion thoroughly
clear in the past:
http://www.twistedmatrix.com/users/glyph/rant/extendit.html
If you structure your application around an mktap plugin, twistd is your
mainpoint, and you get all the advantages I list there of an externalized
mainpoint.
However...
There is a need in Twisted for a much better customization, monitoring,
integration, and configuration tool. Think of the Zope management interface,
but for all protocols, not just web. I have been discussing this with a few of
the core developers, and we're not quite sure where the time to do this is
going to come from yet, but it's clear that this needs to be done.
This is the successor to the current "COIL". If things were implemented in
terms of plugins for _that_, you could write code which would show up as a
nicely formatted icon and description in a spiffy web interface rather than in
a text-based menu listing on the command line. This would be an obvious
improvement for new developers coming to Twisted and wondering why the heck
they should bother with obtuse plugin stuff.
If you have some ideas for how such a thing might be implemented, or you have
some free time and this sounds interesting, I would love to spew more of my
ideas at you. Our initial working model is going to be something like the
Naked Objects framework ( http://www.nakedobjects.org/ ) but I think that more
thought is necessary, especially for metrics display. Web frontends also
present an interesting challenge, because it would be very difficult to mimic
the full flexibility of that graphical model.
Until this becomes available, please stick with mktap when you can, 'cause it's
all we've got. Luckily, some interest has been expressed by various people to
work on this over a sprint on or around PyCon, so this may be resolved sooner
than later.
> naive developers will be confused by the whole thing.. I know it took me
> longer to pick up twisted at first because all of the examples were tap
> based, and not just python code. However, twisted and its documentation are
> a lot farther along these days, so it might be different for a new developer
> now.
I think that the documentation has progressed significantly since you
originally came to Twisted. Let us praise the heroic efforts of Brian Warner,
Andrew Bennetts, and Moshe Zadka. Lore is one of my favorite parts of Twisted
now, and I had hardly anything to do with it :).
--
| <`'> | Glyph Lefkowitz: Traveling Sorcerer |
| < _/ > | Lead Developer, the Twisted project |
| < ___/ > | http://www.twistedmatrix.com |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://twistedmatrix.com/pipermail/twisted-python/attachments/20030211/a5b5edeb/attachment.pgp