[TransWarp] State of Transwarp

[Phillip J. Eby]

At 02:13 AM 6/11/02 +0200, Laurent Martelli wrote:
>Hi there,
>
>First of all, let me introduce myself : I am working on a AOP
>framework for Java called JAC (see http://jac.aopsys.com). I
>discovered Transwarp while searching "python AOP" on Google. It seemed
>to me that the goals of TransWarp and JAC are almost the same, so I
>decided to spy on you :-)

TransWarp's goals have gone through a couple of shifts - first, Python 2.2 
metaclasses removed the need for a lot of the specific AOP mechanisms in 
early TransWarp.  Module inheritance plus metaclass inheritance gives us 
most of the benefits of AOP, albeit without being "pure" AOP.

The second, more recent shift, is the realization that the true focus of 
doing all this in the first place was to build better enterprise-class 
applications, and so we are renaming and re-organizing the packages to 
emphasize that focus.  The tutorial that I'm about to start writing will be 
written from that perspective.


>I've had a quick look at your docs a little while ago, but it did not
>seem very clear which aspects you have working or not. I'm insterested
>in this, because I'd like to compare JAC with Transwarp; We probably
>both have good ideas to share. JAC already have a few aspects ready to
>use : persistence, GUI, associations, authentication, confirmation,
>distribution, session, transaction, synchronisation, tracing. They're
>not all rock solid, but they've at least demonstrated what can be
>done. Does TransWarp have a few aspects that I could play with ?

Not really.  Pure AOP has been much less of an emphasis of late, but AOP is 
still a part of our implementation techniques.

I glanced at JAC; it looks like your work is based on wrapping objects with 
proxies in order to apply pointcuts, is that correct?  It sounds 
interesting, but it's very different than TransWarp's implementation of 
AOP, which actually creates a fresh set of classes with the behaviors, and 
must use metaclasses or descriptor objects to do complex pointcuts.

Nonetheless, it does sound as though your work might be useful to us; 
certainly you've intrigued me enough to want to read more of your 
documentation.  Recent work on Zope 3 has evolved the state-of-the-art in 
Python "proxy" objects, and Zope 3 implements security proxies 
already.  What I'm curious about is how well non-security-related proxies 
would play in the Zope 3 model, since a lot of Zope code requests the 
removal of proxies in order to inspect objects or to bypass 
security.  Obviously, that's not a JAC problem; it's just something I'm 
curious about in the Z3 architecture.