[Zope3-dev] Local site configuration is too hard

[Jim Fulton]

It's too hard on many levels:

- It's too hard for site managers to use

- It's too hard for programmers

   - We make people implement a dead chicken: ILocalUtility.  If they
     don't make this meaningless offering, their objects won't be used
     as utilities. Heck, they won't even be addable to site-management
     folders.

   - The Python APIs for registering utilities are too hard to use.

On the bright site, ZCML is user-friendly by comparison.

We need to do better.  I think we need to review how we got here and
brainstorm and try some different ideas.

Here's a start.  These are more or less random observations:

First, a lot of complexity arose from the desire to support
through-the-database product development, distribution, installation
and update.  This was driven by some issues with updating software in
ZEO clusters.  We eventually figured out another approach for updating
ZEO clusters and have abandoned the goal of through-the-database
development. This allowed us to simplify the local-configuration
machinery quite a bit, as Stephan has recently and heroically done.

The component architecture is very powerful and provides a clean
development model, however, it isn't helpful to force site managers to
use it as the basis of site management. A site manager knows that they
need to add some kind of component, however, they don't understand the
type of the component in terms of a dotted interface name.  I think
that the concept of adding objects to a site to perform a function is
fine. After all, it worked well in Zope 2.  I even think that the
concept of registration is OK, if we can cast it in the right light.
I think it's reasonable that we will need to tell the system whether
and how to use an object is reasonable, but we should make this as
easy as possible for end users.

To make our job easier, we should concentrate on utilities for now.
Zope X3.1 should not include "modules", "page folders" or adapter
registrations. I would go so far as to rip this stuff out of the
trunk. We'll add it back later.

We can't improve things any more before X3.1.  Improving the
site-management experience for managing utilities has to wait for
X3.2.

The pluggable authentication utility is only usable by experts today.
I think it provides a poignant, though perhaps extreme, example of the
challenges if local site management.

I think the basic idea of tools, trying to raise the configuration
abstraction above utility interfaces was sound, however, I think
the execution has not turned out well.  Part of the problem is that the
original assumption was that there would be certain types of utilities
for which there would be many instances, differentiated by name.  For
example, there might be multiple database adapters, or multiple
caches.  In practice, there usually aren't multiple utilities of the
same time.  Even when there are, there aren't many.  Treating tool
types as virtual folders is way to heavy in most cases.

Another problem with the existing tool mechanism is that it creates
virtual folders that hide site-management folders.  I don't think this
is really helpful. It makes things more mysterious.

Content managers add objects to folders to build a site.  What's
wrong with site managers adding objects to folders?  Nothing, IMO.
I think it's helpful to review how we got to where we are.  We used to
have lots of registries: Services, Utilities, Database Adapters,
Caches, etc...  People had 2 places to manage components, the
individual registries and the site-management folders.  We decided to
try emphasizing the registries and deemphasizing the folders.  OK, we
tried and, I think, we failed.  The current UI is mysterious.

I suggest going back your our Zope roots.  Managing a site should
happen by adding objects to and managing objects in site-management
folders.  When we add an object to a site-management folder, we offer
to register it.  We offer two registration interfaces. The default
interface checks to see if the object provides any tool types.  If it
does, it offers to register it as one of the tool types, showing the
tool descriptions (rather than dotted interface names).  There can be
an advanced interface that shows the actual interface names as we do
now. Perhaps there could be a button for toggling between the advanced
and basic interfaces. In general, however, we need to bother to
provide a registration UI that sucks a lot less than what we have
now. In particular, we need to provide some helpful text that explains
what all of the inputs mean.

OK, enough for now. Thoughts? Comments? Anybody else have any ideas?

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org