[Twisted-Python] Components

[Christopher Armstrong]

Glyph Lefkowitz wrote:
> 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
> trivial.
> 
> 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.) 

You're right, the developers probably had vastly different applications 
in mind. However, the only technical difference I notice in the 'game 
simulations' arena is Componentized, and that's actually a fairly simple 
thing (In fact, from what I read in the PyProtocols documentation last 
night, it seemed like similar things already exist, or could trivially 
be implemented).

You can talk about 'different philosophies', but that's meaningless 
until you say what technical differencies you actually mean. Maybe you 
could explain what aspects of twisted.python.components you consider are 
more simulation-oriented? I'm sure it's not that hard for you to squeeze 
down your '5 or 6 pages', as I've seen you explain various Reality 
concepts in much less text, and we have an audience that's very familiar 
with component systems, interfaces, and adapters here. Maybe Jp can jump 
in, too, as he was the one who originally brought up the 'difference in 
philosophies' point.

As far as the technical stuff goes, PyProtocols and t.p.c do the same 
thing, and PyProtocols *can* do everything we have and want, at least 
from what I've recently heard people want (string adaptation, 
Componentized, adapter contexts...).

> 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,
> http://peak.telecommunity.com/Articles/WhatisPEAK.html
> 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 :)

Yeah, reading PEAK's web site is pretty amusing. otoh, our own web copy, 
while less 'professional', is also pretty lame :-)

-- 
  Twisted | Christopher Armstrong: International Man of Twistery
   Radix  |          Release Manager,  Twisted Project
---------+           http://radix.twistedmatrix.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: </pipermail/twisted-python/attachments/20040227/901c2265/attachment.sig>