Skip to content.

plope

Personal tools
You are here: Home » Members » chrism's Home » The Zope 2/Zope 3 Dilemma » schtuff
 
 

Comment

Above in this comment thread: The Zope 2/Zope 3 Dilemma

schtuff

Posted by chrism at 2004-06-01 10:15 PM
I'm at least a little dubious of using Zope 3 code in Zope 2 if only because there really isn't much in Zope 3 that isn't in Zope 2 already. I guess things like schema and filesystem sync are part of Zope 3; these aren't in Zope 2. But Zope 2 has Archetypes and FSDump/skins. Amd so on. If I had my way, I imagine I'd be happier coding in Zope 3 with Zope 2 bits a safe distance away. But you're right; the only way I'll get to do Zope 3 coding soon is to use the Frankenstein mode for some customer projects.

As far as R&D goes, I think there's a bit of marketing dance that needs to happen for a product to attract R&D work. It needs to do something unique out of the box or have a "killer application". In the early life of Zope 2, this was Squishdot and (believe it or not) Zope.org. At the moment for Zope 2, it is Plone. Maybe someone will create something like that for Zope 3 soon and it will grab a hold of folks who will be able to convince their bosses to invest in it, even though it's new.

Five

I've been working on the problem of mixing Zope 3 into Zope 2. It's not that hard (after convincing Jim to make Zope 3 interfaces interoperate with Zope 2 :). The result is Five, which can be found here (will move to new repository
in a few weeks): http://cvs.infrae.com/Five/

I can do adapters and views. Views are still a work in progress. It only depends on zope, not zope.app, so far.

ZCML

Like it or not, one of the things that Zope 3 does is ZCML. Five does ZCML in straight Zope 2.7. :)

Potential killer app

I have a friend who is considering moving his research development tools from Matlab to SciPy (and other Python modules). The guy is into image and signal processing. From what I understand from Zope 3, "products" will be much closer to standard Python modules, so that code developed for Zope 3 has a better potential for reuse in other Python apps. That goes the other way around. All of this to say that something like SciPy could benefit a lot from a CMS to store data, algorithmic definitions (in some declarative form maybe ?) and above all system users, who would be granted different data drilling or analysis capabilities as a function of their membership level. I know "killer app" usually refers to something the general public can be hooked on easily and what I am proposing, that is to try and unite the CMS capabilities of Z3 with the computing/analysis capabilities of SciPy (or any other Python product that targets a specific problem domain for that matter), is not a "general public killer app". But it would be a scientific (that is university, research centers ...) vertically integrated killer app and knowing how much skilled resources there are in universities, bringing Zope in research/academic facilities through the "science" door might pave the way to its use on a wider scale.