[TransWarp] PROPOSAL: Rename "TransWarp" itself

[Phillip J. Eby]

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:

J2EE       TransWarp
====       =========
JavaBeans  TW.CIS
JNDI       TW.Naming
JDO/JDBC   TW.Database
Servlets   Zope
JSP        DTML/ZPT
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 
time.  :)

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:

http://www.tundraware.com/Technology/Python-Is-Middleware/Python-Is-Middleware.html

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 
mountaintop...

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.