[TransWarp] Building PEAK apps with Zope X3

[Phillip J. Eby]

[copying this part of my private reply to the list, since it's potentially 
of general interest]

At 07:46 PM 4/9/03 +0200, Ulrich Eck wrote:
>I'ld like to (help afaic) work towards **one** interfaces and **one**
>persistence package that can be used for PEAK and Zope-X3.

Me too.  I am still probably going to hold off on updating the interface 
package for a bit, because I think that if my proposal to Jim about PEP 246 
is accepted, the way that PEAK uses interfaces may be able to change quite 
a bit.

Actually, I wonder if maybe I shouldn't just go ahead and adopt PEP 246 in 
PEAK, and make 'peak.util.interface' a way to shim backward compatibility 
in.  So, for example:

from peak.util.interface import Interface, implements

class ISomething(Interface): pass

class Something:
     implements(ISomething)


PEAK only depends on a subset of the full interface package 
functionality.  Currently, we check if something implements something, and 
that's about it.  In future, I'd like to change this to a PEP 246-style 
'adapt()', e.g. 'adapt(something,naming.IName)' would take the place of 
'naming.toName()' (or the latter would just be a shortcut for the 
former).  Once this is done, it will no longer be done to query whether 
something implements an interface; instead one will call 'adapt()'.  In 
some sense, it is none of your business what interfaces an object 
implements itself, versus what it delegates to another object.

Anyway, the key point here is that PEAK would then have a nicely narrowed 
-- and stable -- definition of what interfaces do.  (It's actually pretty 
narrow now, but this would narrow it further.)

I guess I should also clarify that interface compatibility between PEAK and 
Zope X3 *is* a requirement for PEAK, from my point of view.  I don't 
consider the same to be true for the persistence system; officially it's a 
"nice to have" for PEAK, since if you really need it for a PEAK-based 
object, you can always write a DM that yanks the state out of the PEAK 
object and slaps it into an attribute of a ZODB object.

One thing I should point out, if you plan to use PEAK with ZODB, is that 
PEAK and ZODB have wildly different transaction protocols.  ZODB doesn't 
support cascaded storage, but does have transaction "savepoints", while 
PEAK is the other way around.  So if you plan to use ZODB in the same 
application as PEAK, you have your work cut out for you right from the 
start, *even if there's only one Persistence base class*.  Note that this 
affects zope.publisher, in that your Publication object needs to either 
start and stop two transactions, or you need to have an adapter from one 
transaction protocol to the other.  If you look at the CVS logs for 
peak.storage.transactions, you'll see where at one point I had a prototype 
of such an adapter.  I threw it away after a while because at that time the 
ZODB4 transaction protocol was in flux and I couldn't keep up, not while 
PEAK's transaction protocol was also in flux!  Anyway, this is the single 
biggest integration risk if you expect to use Zope X3 or 3 with PEAK -- and 
not as a pure PEAK application that just happens to be published via 
'zope.publisher'.

What I currently anticipate, is that PEAK will provide a custom Publication 
object, a custom SecurityPolicy, and a few other such top-level components, 
in order to permit creation of web apps.  But it's unlikely in the near 
future that PEAK will natively support ZODB-based Zope X3 apps, unless 
someone contributes patches for PEAK (that are simple and maintainable).

I'm also not yet certain whether PEAK will bundle an entire Zope X3 
installation, or just the parts critical to its operation (e.g. persistence 
and zope.interface), or something somewhere in between (maybe 
zope.publisher, zope.security, and some templating tools in addition to the 
basic requirements).  I'd like to make it possible for people to use PEAK 
on a "batteries included" basis, but then I'd like to not have to mirror a 
significant chunk of the Zope CVS, either!  So I'll probably end up just 
bundling the critical parts, and making the rest dependent upon Zope being 
installed on sys.path.