[Zope-ZEO] Advice

[Ken Manheimer]

On Thu, 21 Sep 2000, Greg Ward wrote:

> [I crudely slag Zope]
> 
> Personally, my gripes with Zope boil down to one fundamental
> disagreement:
> 
>     code != data

> [...]

> I suspect Zope is very good at content management, which I understand is
> what it was designed for in the first place.  Zope's model is that
> content (data) is king, and logic (code) is ancillary and not very
> important.  (If you can't version control it or grep it, how important
> can it be?)  The model that makes sense for application development is

I don't agree that zope treats code as ancillary/not very important!
I *do*, however, think there are deficiencies in its treatment of the
recent *extensions* of its model for code, because those extensions -
stuff for through-the-network (eg, t-t-web) - are to varying degrees
works in progress.

1. Formerly, the primary way to extend/programming zope was using
   filesystem-based products and extension methods.  t-t-w DTML
   documents were intended for presentation - but even then that was
   being "stretched" (abused) because the power of through-the-web is
   just too tempting.

2. ZClasses, python methods, perl methods, XSLT methods, etc, are
   only recently emerging to cooked states, or in the process of
   being cooked.  They promise some big power, and are starting to
   deliver, but there are missing pieces.  Paul described a path
   towards version control and other-than-web network access modes,
   which will provide those pieces.

   It's not there yet, but there are many ways to manage the ttw stuff
   with only a little hassle - and with the big benefit of ttw access.
   Eg, there are many ways the "feeble text widget" problem is being
   addressed - store the code in the file system, and transfer it in
   (via ftp, or mouse cut and paste, or whatever - i have a directory
   full of the tracker forms checked into the tracker's CVS
   repository, wouldn't do without it!)  Use the history mechanism to
   see versions of your edits.  Etc.

The point is that it's workable, and it's going to get better, because
when you have a good content management system (which zope increasingly
is), "code == data" means you can use the system to manage and extend its
own development.

The ability, in general, for people across the network to do development,
may be the most crucial advantage of open source.  Ie, those bitten by
scaling limitations (and other bugs) have recourse (source and access
path) to rectify them, if they have enough motive to do so.  This way, the
scaling limitations that really need to get fixed, do, and increasing
access with increasing scale means stuff worth growing, does.  !

The contemporary way this happens is that everyone has their own copies of
the system on their own hosts.  With Zope, the development can happen over
the web.  We need more mechanisms to coordinate that - we still need basic
scaling provisions - but it's increasingly the case that the people who
develop it use it to do that development, they "eat their own dog food" -
the content management system will be tailored to real usability as the
rest of Zope grows, and not to marketing conceptions of usability.

> In my experience, Zope is not very good at application development,
> because it doesn't let you do the natural things programmers like to do
> with source code.  (Also, DTML is a pain in the neck, but that's a minor

I wish you would have qualified that, because it seems like you're
referring just to through-the-web products, which are only part of the
story, as i said above.  The filesystem products are totally susceptible
to the standard tools, and totally viable ways of developing.  I accept
that we are deficient insofar as we failed to make either that fact or the
process of doing the development sufficiently clear.  That's a big problem
- but a different one (and one we continue to work on, with varying
degrees of success).

> with source code.  (Also, DTML is a pain in the neck, but that's a minor

(DTML is overdriven.  We're hopeful that there may be relief from that
in the recent templates-or-whatever-you-call-them movement...)

> Of course, the database that our code serves up is a ZODB/ZEO beast,
> which is why I'm on this list!  There are many very cool bits and pieces
> of Zope, and ZODB/ZEO are probably the coolest.

I totally agree that there are lots of extremely cool pieces, and am
very happy that you and andrew are helping get the word out about
them.  I happen to think that the framework which Zope embodies is
much greater than the sum of its parts.

Ken
klm@digicool.com