[TransWarp] peak and zope3

[Phillip J. Eby]

At 02:54 PM 1/14/03 +0100, Ulrich Eck wrote:
>Hello Phillip,
>
>I'm prototyping some infrastructure for our application
>and want to combine peak and zope3.
>
>What potentional problems are there ?
>
>- incompatibilties of Interface/Persistence packages
>   after z3 namegeddon, the Interface packages is now
>   known as zope.interface, the Persistence package
>   is now known as persistence. the module-names have
>   changed.

Yep.  Interface is definitely not compatible.  But having the same 
persistence implementation is only a requirement if you want to persist a 
Z3-supplied persistent object with PEAK, or vice versa.


>   are there any plans to get in sync with zope3 packages

Eventually.  To be honest, I've been so busy at work lately that I forgot 
about the namegeddon issue altogether!


>   and what are the problems there if any ?

Don't know yet.


>- Persistence/Interface package modifications.
>   afaik you made some modifications to persistence and
>   interface that did not (yet) make it into the original
>   sources. Are there any talks/plans going on to overcome this.
>   if not .. is there a chanche to use one of/both for peak/z3 ?

AFAIK, Interface should be compatible, in that my patches made it 
back.  Many of my patches for Persistence have not been accepted, 
however.  I'm not sure why, since I included tests to show why the existing 
package was broken.

Anyway, the irony is that Interface is compatible, but won't work right if 
you have two versions in different namespaces.  Conversely, Persistence 
isn't the same, but will probably be able to work under two different 
namespaces.



>- ???
>
>Basically i want to create content-types from elements, manage
>them in DataManagers and supply views in zope3ish style. Furthermore
>i'ld build services from components on the server side.

In principle, I'd say that, once you get the Interface vs. zope.interface 
issue fixed, any problems you have with the above use cases are Zope bugs 
rather than PEAK problems, since Zope 3 has made it a goal to support 
"foreign objects" in those roles.  However, I don't believe that all Zope 3 
community developers care about that issue enough to be vigilant in their 
design and development efforts, or that all Zope Corp. staff are 
necessarily aware of where such issues exist or might exist.

So I guess you can look at this as an opportunity to improve Zope 3's 
compatibility with outside frameworks.  ;)



>I want to build the ClientApplication with wxPython using a similar approach
>than you do for reading/writing XMI/MOF (data from xml-wx-resources and
>schema is used to build the necessary components for the GUI)
>
>Threrefore i would use Zope3 server as kind of middleware that manages
>security, transactions, concurrency, persistence (partly).
>
>is this possible yet .. if not, what needs to be done to make it work ?

In principle, it should be possible now, if you rely only on 'zope.*' 
packages and not 'zope.app' packages.  Otherwise, you may run into 
interdependencies and assumptions that won't be met.

In principle, you should also be able to replace much of what used to be 
called the ComponentArchitecture module with PEAK component tools.  Utility 
lookups, for example, but also services and adapters, could be done using 
PEAK.  I'm not sure whether we'll do that ourselves; it depends on how 
useful ZCML turns out to be and how much integration with PEAK 
configuration we need for such things.  If we end up using ZCML just to 
define security and views and such for Zope, then there'll be little 
overlap or need for overlap, and we won't bother with such "brain surgery" 
to merge the two.