> 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 ...


Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to