[Zope-dev] TransWarp preview release (AOP tools only)

[Shane Hathaway]

"Phillip J. Eby" wrote:
> 
> At 09:37 AM 3/1/01 -0500, Shane Hathaway wrote:
> >What is your vision of integrating AOP into a persistent object system?
> >Would one drop in an object that modifies the class loading mechanism so
> >that the classes come from a TW component rather than Python modules?
> 
> Not necessary.  If you dig into the TransWarpFAQ page in the Wiki, you'll
> see a question that explains how to make TW-generated classes work with
> pickle and cPickle.  It just requires one additional argument at
> aspect-weaving time, to specify the module which the generated classes
> should be registered with.  This means that TW's AOP features are
> functional right now, today, with ZODB.  (As long as the classes are
> generated in good ol' Python module files.)

Okay, here's how I think AOP could be applied to a current project.

We've been separating concerns in the PTK/CMF for the last year now. 
We've been moving as many responsibilities of the content objects as
possible into per-portal "service" objects.  The services provide user
interface, discussion capability, workflow integration, etc.

In doing so, IMHO we've lost a little simplicity.  In the current way of
doing things, content objects should not know about their own workflow,
instead they should be associated with a portal-specific type object and
the type object is associated with a set of workflows.  And the user
interface depends heavily on acquisition now.

Now, let's say that instead everything were reintegrated into the
content objects using aspects.  To retain flexibility, different portals
would weave the content objects in different ways because of variations
in user interface, workflow, etc.  Would this be a good application for
TW?

This could be achieved by generating a new Python module for each portal
instance, but that would mean sys.modules would have to be pre-loaded
with the information about each portal instance and that's not the ZODB
way.  It would be better to create a new class loader that can weave a
new class on the fly based on persisted component metadata.  Note that
class loading is currently quite simple; see
lib/python/Zope/ClassLoader.py (sp?).  It could bear some complexity.
:-)

> Now, as to whether TW will be fully compatible with Zope 3 "persistent
> modules", that's a different question.  In the conversation I had with Jim
> in January, based on his description of the module refresh mechanism and of
> import proxies, I would say that TW-generated classes would not properly
> refresh when a persistent module that they were dependent on changed.
> (Because TW will generate new class objects from the imported classes
> rather than referencing them via the proxy.)  But that's based on a very
> early notion of how Z3 persistent modules would work.

I don't see how persistent modules can work unless they are highly
restricted.  The idea is that modules would be "executed" only once then
the result of that execution would be stored in the ZODB.  But there are
a *lot* of things that can't be persisted, like thread locks.  You'll
have a hard time persisting a module like this:

import thread

lock = thread.allocate_lock()

def foo():
    lock.acquire()
    try:
        print 'got the lock'
    finally:
        lock.release()

Maybe this has been solved, I don't know.

> One reason I've been racing like mad to get the preview release out is so
> that, after seeing the usefulness of TW for the Zope 3 component
> architecture, y'all might be interested in considering implementations for
> module persistence besides proxying.  :)  IMHO, a "rollback importer"
> approach ala unittest might be better suited for TW-ish components, and
> have fewer weird side effects for persistent modules generally.  I don't
> like unittest's mechanism for *doing* the rollback, and Zope would need a
> thread-specific version of sys.modules, as well as a mechanism to purge the
> cache of any objects which were loaded after any of the purged modules, but
> I think the basic idea is sound.

Hmm.  I'm afraid I don't see how TW helps with module persistence.

Shane