I am not too active on the Zope mailing lists any more because there is not too much time left for it. But this thread asks for a comment. So here it is:
First of all, I am not sure if the release policy of Zope 3, and the whole concept of doing a complete rewrite was right or wrong, but at least I don't see a much better alternative. Zope 2 really is getting ugly with its age, so just fixing it wouldn't really be too much fun.
What I've been missing in Zope 3 fro years now is a clear focus on a single target. Maybe that is the target of Zope 3: not solve a specific problem like web content management but be a general toolkit for building applications.
But I think it would have been a bit easier and much more efficient to start with a rather focussed project, let's say a web groupware system or a CMS, then make sure that things don't get too specific. That way there would have been a list of deliverables to test all the neat new features and concepts against, not just conceptual ideas.
As things are now, me and lots of other commercial Zope users never had the resources to really actively participate in Zope 3 because we have to earn our living, and that means applications for the end user if we don't want to charge for the toolkit (which is obviously no option).
Well, it's not too late for this. The world still doesn't have the perfect groupware or CMS application, and maybe Zope 3 can be a starting point for it.
The problem of Zope 2 is - don't kill me for saying that - Plone. Plone and its foundations in CMF have created a large momentum around a terribly horrible code base. Believe me or not, almost everything gets more complicated with CMF/Plone than with plain Zope. Building a framework on top of a broken framework on top of an ageing framework that is hardly documented isn't a very good idea after all. The shortcomings in Zope 2 itself should have been addressed and fixed, rather than reinventing most of its good parts poorly and keeping the bad parts. Send me a private mail for an extensive list of issues I see ;-)
There are quite a few Zope-based CMS solutions out there, and most of them are better than their commercial counterparts in many respects. But if we had managed to start a joint CMS effort (other than CMF, which is a failure by design) two or three years ago things would look even better now.
I am currently working on a prototype for a project management solution that is going to be used at SUSE LINUX AG. For that I am using plain Zope. No Archetypes, no Plone, no nothing. Why? Because while Zope 2 is ugly in many respects it still is the most beautiful solution in the Zope (2) community. The original Zope concept is great (having a filesystem-like structure of objects and a web-based frontend to work with it). What I expect from Zope 3 (at least as one part of the project) is a better replacement for Zope 2.
The few problems I have always had with Zope 2 haven't been addressed in Plone. They probably have been addressed in Zope 3. I'll have to find out. What I am looking for is a real rapid development tool for web-based (or at least distributed) applications. If Zope 3 doesn't deliver that then other solutions will "win the war".**
Rapid development can only work if there is an easy-to-understand concept or basic paradigm in a system. Zope 2 is such a system. A lot of things just got ugly because too much bloat was added later. One of the best ideas with the worst implementation was ZClasses. ZClasses would be extremely useful if they really worked as expected. In the web frontend all we'd have needed is a separation between configuration stuff and data (e.g. using two or three tabs instead of one mixing everything). Zope 3 has addressed this issue quite well I guess.
What we should work on in the future is development tools for Zope. If I get the stuff I know about Zope 3 right it should be relatively easy to write IDEs (or plugins for existing IDEs) that add wizards, code-completion and lots of introspection, so that I don't have to learn all the API but can explore it while developing.
Add an UML-based or UML-inspired graphical frontend to do the application architecture.
Finally we need industry-strength performance. The last point is one of the most important ones. Zope 2 has lots of very nice features (like the ZODB, WebDAV access, etc.). Basically everything is there to replace a lot of the most recent Microsoft products (including their planned WinFS DB-like filesystem). We are just lacking the performance (mostly thanks to Python being a beautiful, but not really fast language).
That's from my part.
Cheers
Joachim
** A final question that is mainly aimed at the ZC people: What is the competition you are positioning Zope 3 against? I've never seen an answer to that quite important question ...
-- iuveno AG Joachim Werner
Wittelsbacherstr. 23b 90475 Nürnberg
Tel.: +49 (0) 911 9883 984
E-Mail: [EMAIL PROTECTED] WWW: http://www.iuveno.de
_______________________________________________
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
