Hi! > To be honest i would be happy for Zope 3 not to be backwards > compatible. Tidy it up, delete the unless code, dare i say it - > refactor. Yes so my products will break, well half a days refactoring > myself and i have a tidier more understandable project anyway.
YES, we need a new start. Building on what we have now, of course, but doing things better without having to think about all the legacy stuff. When I see long-time Zope users like Tom Schwaller (who is a Linux legend in Germany) move on to something new like Webware for Python, that makes me wonder if Zope is starting to loose some of its momentum. Zope is a great product. And it becomes easier to sell it every day. But it could be so much better and more easy to use with just a little effort. Just to mention a few points: What we really need is >>> A true vision of what Zope 3.0 is going to be <<< Zope 2.x, together with the CMF, was "sold" bei DC/ZC as a content management product, which it isn't really. It is a good start for building one, but so many things that are mandatory for a CMS are missing in the out-of-the-box installation. Zope is a nearly perfect document storage, except for its server implementations for FTP (and partly also HTTP/Web-DAV) will not be too useful with major system load. Zope + Python are a dream team for web-based applications. I think that a single product can't be good at all these things. But I also think that Zope could emerge into a suite of near-perfect products for web-based internet and extranet solutions. I think Zope should be split up into components as soon as possible: - a database layer that includes alternatives to the ZODB (using products like DBObjects or the new stuff from 7x - a document management frontend to the database layer that can be used to manage all kinds of docs. Together with add-on products like the document library, Zope already does much of this, but it is not optimized for high loads yet, and products like Microsoft's Sharepoint Server are really coming close now. I wonder why people in the open source community seem to ignore what Microsoft is doing. I don't ask you to USE their software, but we should at least try to get inspired by the good ideas they have (or have collected from others who had them first). What we need in that part of Zope is high-performance real-time cataloging and searching, interoperability with FTP, WebDAV, maybe even SAMBA and NFS, automatic document conversion from Word/PDF to HTML etc. - an application development framework. Here, we need some more work done towards a real IDE (for Python and Zope). A lot of work has been done already by people like Riaan (who maintains Boa Constructor). Most of DTML (if not all) should go, and Python as the main programming language for Zope should be in the focus of documentation and training efforts. I spent more than a year with getting good at DMTL, just to find out in the end that ZClasses/DTML are really limiting and that developing in Python is almost as fast and much more effective. We need full integration between ZODB-code and filesystem code for that. We need ways of doing ZClass-like things with real Python code, and we need CVS-compatibility or something better within Zope. XML-RPC/SOAP/Webservices could be a strong part of this. - a real, complete, out-of-the-box CMS, based on the other three components. I know that there are at least a dozen good CMS BASED on Zope, but this seems to me to be a waste of resources. We only need one good system that can be maintained by many people. It needs a high-level plug-in architecture, so that people can contribute modules that can interact with each other. Currently, most Zope products other than the database adapters and user folder implementations are standalone products. Let's take Squishdot as an example. It is cool, yes. But it is not compatible with anything but itself. The CMF was a first try to build a standard Zope CMS, but it still far from being a good solution. It solves problems you don't have and takes away solutions plain Zope can offer, like being able to build hierarchically structured sites (as it has a flat member paradigm). What we need for the CMS level is: - easy-to-use (partly WYSIWYG) editor tools - a chroming/skinning mechanism that is used by all components - workflow - ... - on top of all that, I see really sophisticated systems like (real) portal toolkits or groupware software. - one of the remaining questions is: Does Zope need a stronger XML story? I think that Zope Corporation doesn't want to maintain all of that, and that they actually wouldn't be able to do so. So it is really important to make sure what will be part of Zope 3 and what not. And who is going to be in charge of what. Wow, this has gotten rather lengthy (and still incomplete). But maybe I'll get some feedback on this ... Joachim _______________________________________________ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
