[TransWarp] Re: PROPOSAL: Rename "TransWarp" itself

[Jean Jordaan]

This reminded me of an interview with Alex Martelli:

> I think that "Python Enterprise" needs to be a larger movement than just
> PEAK.  Zope is a part, and other Python efforts like the new Persistence
> (and Transactions) SIG have a role to play as well.

I attach the relevant paragraphs from the interview below. It looks as
though the Strakt framework and PEAK solve some of the same problems.
The interview is at:
  http://europython.zope.nl/interviews/entries/alex_martelli

--
Jean Jordaan
Upfront Systems                         http://www.upfrontsystems.co.za

Ah, now that is a really exciting prospect, too! Strakt people have been working on it for quite a while -- I've been with Strakt
for only 4 months, so my own contributions have been reasonably modest so far, but I can at least recognize brilliance when I see
it:-). Tier 0 is any good RDBMS: we've been working with PostreSQL so far, also keeping an eye on Oracle, but I'm confident that we
could substitute any really good RDBMS (such as, say, SAP/DB, nee Adabas -- or IBM's DB2 -- and so on), as we're not using any
deeply nonstandard features. And that's brilliance #1 -- don't reinvent the wheel when Michelin and Bridgestone are eager to supply
you with most excellent ones already. Brilliance #2 is that every other tier is in Python. With suitable support by C-coded or even
C++-coded extensions where needed, to be sure -- but such needs are quite localized, and mostly rely on existing extensions (DB
interface, web interface, GUI, ...). Where Strakt has had to develop its own extensions (for security, using SSL) it has made them
Open Source to get the advantages of the open source model (and I count that as Brilliance #3).

And this is where the fun begins! Tier 1, called the "Infinite Filing Cabinet" (IFC), is an O-O database (built on top of a
relational DB) like no other, with a strong real- time orientation (you can "subscribe" to some object, or to a query, and get
notified in real time each time the object or result set changes) and an intrinsic "audit trail" of changes. Tier 2, provisionally
called BL (for "business logic"), builds business objects on top of the services that the IFC provides, so that every other
"downstream" tier can deal directly in high-level, application-oriented terms. Moreover, the BL works in a highly modular way,
dynamically loading (from the IFC) Python-coded "business logic modules" (BLMs) that do the application-oriented work on top of the
BL infrastructure.

One can reasonably count the BLMs as "Tier 3". That is one spot where I did contribute a little, developing a "little language"
(actually a collection of Python classes and functions) that lets the BLM itself be coded in application-oriented and quite high-
level terms -- terms quite close to an entity-relationship diagram, typically -- although, of course, the BLM author has the full
power of Python at his or her disposal whenever the "BLM Little Language" does not meet all needs. Moreover, the BLM can also
include, besides business logic, whatever presentation-level information and actions are specific to the application area it deals
with -- the presentation level executes in Tiers 4 and upwards (AKA the "front-end" parts of the framework), but the information and
specific code that defines its appearance and behavior may still reside in the "back-end" parts of the framework (Tiers 0 to 3) --
coded in the BLM which in turn is stored by the BL in the IFC which puts the bits in some tables of the relational DB. If this makes
your head spin, don't worry -- took quite a while for ME to grasp it all, too:-). I think this whole 'back-end' part must count as
Brilliances #4 to #8, at least (actually, there are quite a few more than that "behind the scenes", making the whole apparatus work
so smoothly and rapidly, but let's be conservative in our Brilliances-count:-).

And so, we come to Tiers 4 and upwards -- the "front-ends", also somewhat inappropriately known as "clients" in the framework.
"Somewhat", because some of them are indeed clients -- for example, a GUI client (coded on top of Qt, for cross- platform
deployability and performance), and a batch client (which runs Python scripts, of course:-) that we use for such tasks as testing,
creating ("populating") sample databases, and so on. But other front-ends are, in turn, servers -- for example, a Web server, coded
on top of Webware, which lets web browsers access a substantial set of the framework's functionality (not the real-time aspects, at
least not so far -- "push" technologies appear to be somewhat out of fashion, and portable, cross-platform access to information
updated in realtime from any standard browser requires some interesting technological choices).

The front-ends are quite open-ended -- together with the ability to write and load BLMs, the front-end architecture is what makes
this Framework exactly that -- a Framework, not just a software tool. Let's count all that goes on in tiers 4 and upwards as
Brilliances #9 to #12, to round up a conservative dozen, and we'll make it into a baker's dozen by prefixing Brilliance #0 -- all
the aspects of agile methodologies, and the human aspects of the AB Strakt team, that made the opportunity quite irrestistible for
me when I got the offer of joining it. Consider, for example, that I live in Bologna, able to spend in Sweden less than a week a
month, on average -- yet, thanks to AB Strakt's culture, I'm still able to blend in quite well, by teleworking, and I feel as
involved, as much a part of the team, as everybody else.

We have lots of plans about deploying and growing this Framework, of course -- starting with a "help-desk" application, built on top
of it, which we'll shortly be installing in beta form at our first customer. Integration with all kinds of other systems comes quite
natural to the Framework, thanks in part to its own architecture, in part to Python's superb suitability for such integration work.
For example, we'll definitely develop integration with e-mail systems, and the like. My own personal pet project is to have a
"midget" version of our fundamental GUI client running on my new toy, the wonderful little Sharp Zaurus hand-held... both the GUI
client and the Zaurus are based on Qt (via PyQt), which I think will ease my task considerably.