[TransWarp] PROPOSAL: Rename "TransWarp" itself
Phillip J. Eby
pje at telecommunity.com
Sun Jun 9 21:30:52 EDT 2002
As I continue thinking through the tutorial outlines, a distinct theme has
been emerging: TransWarp is actually a Pythonic form of J2EE. Look at this:
EJB TW.SEF (+naming & config systems)
JMS Vinculum (a long-standing codename, but no specific impl. yet)
And so on. Yes, there are some CASE and AOP bits still hanging on in the
bowels of TransWarp, but not only are they not ready-for-primetime, they're
not really the *point* any more.
The TransWarp name was originally coined as a placeholder, to imply
development speed, and to suggest weaving (the term "warp" originates from
weaving - it's the fixed vertical threads in a loom). The weaving
reference is of course meant to imply the aspect weaving of AOP. Last, but
not least, Ty and I had a STNG/Borg theme going with code names at the
But the TransWarp name doesn't say anything about what TransWarp is really
*for*. One concept I've batted around for a while now is that "TransWarp
is a framework for implementing non-functional requirements." That is,
it's a framework for the "ilities" of an application: scalability,
configurability, extensibility, flexibility, reliability, and so on.
But even that doesn't really offer a quick mental hook for someone to grasp
an answer to the question, "but what do you *do* with it?" And today I
realized that the answer to that question was in front of me the whole
time, but it was invisible because I live in it...
Specifically, I design, develop, and maintain enterprise
applications. (Enterprise? There's that Star Trek theme again...) Many
of the pieces of TransWarp and AppUtils exist because of specific
development issues that came up repeatedly in building such
applications. Deployment. Configuration. Task management. Component
integration. Layering. It's understandable that we'd end up, in some
senses, inventing the same wheels that the J2EE folks have been building,
for the same general development space.
After I started writing this proposal, I googled "J2EE Python" to see what,
if anything, is already out there regarding this subject. I found a very
interesting article at:
Some points of relevance to TransWarp are in the "Flies In The Ointment"
section, wherein he notes that "SEMANTICS MATTER... STRUCTURE
MATTERS... CHANGING UNDERWEAR MATTERS... and IN-STOCK AT K-MART
MATTERS." These are *precisely* within the non-functional requirements
space that TransWarp lives for.
So... TransWarp is middleware. TransWarp is (or rather, will be) J2EE -
or to be precise, an alternative to J2EE in the Python space. Does it
still make sense to call it TransWarp, then? Especially since the name
focuses on implementation techniques (AOP, GP, etc.) rather than on
goals? (Enterprise Application Develoment.)
I think the current name -- and the baggage that goes with it -- will get
in the way of it reaching a wider audience - the kind of audience that's
really needed for it to be anything other than a neat little toolkit used
by only a handful of people besides Ty and me. So I'm proposing a name change.
The best name I've thought of so far is the Python Enterprise Application
toolKit (PEAK). It's short, has positive connotations, and even lends
itself to a nice logo concept, perhaps rendering the "A" in PEAK as a
I am, however, open to suggestions from one and all. The change would be
implemented sometime before 0.2 final, by copying the TransWarp CVS tree to
a new location and branching it off. The old TransWarp code would
dead-end, with maybe a few bugfixes being backported for a brief period to
help support Ulrich and anyone else who might still be using it. The new
code would also have some package renaming/reorganization to better reflect
the adjustment in vision/definition of the package.
Comments, questions, and feedback are welcome, encouraged, and requested.
More information about the PEAK