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/