[Twisted-Python] Components

Glyph Lefkowitz glyph at twistedmatrix.com
Fri Feb 27 00:24:54 EST 2004

On Thu, 2004-02-26 at 19:47, Phillip J. Eby wrote:

> Yeah, my problem is that I don't usually write stuff to solve simple 
> problems, because if it was a simple problem, somebody else would probably 
> have already written something to solve it, and I could just download their 
> implementation and be done with it.  :)

> So, when I write something I'm almost invariably thinking about *hard* 
> problems, and that tends to carry over into my documentation.

I can understand that inclination myself, having more than once heard
Twisted accused of being "an impressive solution for which there are no
problems".  However, PEAK's documentation has been dense even for me.  I
certainly could not accuse if of not being thorough :).

In a discussion with another Twisted developer, it struck me that we may
be coming at the problem of components from completely different
angles.  I didn't understand why components were interesting at all
until I started to play with using them in the context of separation of
concerns within simulations.  Since these concerns can become
independently quite large, manage independent state, and are largely
interrelated only at relatively few boundary points, they're well-suited
towards collections of stateful adapters.  Compared to the use-cases
I've attempted to satisfy there, every usage of adapters has seemed

Looking at PyProtocols, it doesn't seem to me to have taken simulations
or gaming into account as a use-case.  An indication of this is the
seperability of the full component model from the interface / adapters
system.  Without a full understanding of the execution context of an
adapter, I don't know how I could integrate external adapters like TTW
login or email delivery into a simulation.  (Pardon me for not being
terribly specific here.  It's difficult for me to come up with examples
that take less than 5 or 6 pages of dull prose to explain.) 

However, I am not sure, because I can't figure out what PEAK as a whole
is really for.  The likely source of an explanation,
seems awfully vague.  What is the problem that PEAK was designed to
solve, exactly?  Clearly it was difficult, because there was a lot of
solution :)

        An aside, for any would-be component system or documentation
        authors in the audience: much general literature on the use of
        components - including the Twisted component tutorial, I might
        add - is maddeningly vague, somewhat like "object oriented
        programming" tutorials.  I don't need to simulate simplistic
        bicycles or shapes or electrically incapacitated hairdryers, I
        want to write networked applications and video games, and it's
        not clear which concerns I should separate, how, and when.  Why
        does this stuff help me?

More information about the Twisted-Python mailing list