[Zope3-dev] Local site configuration is too hard

[Garrett Smith]

Jim Fulton wrote:
 
> 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.

I never really tried to understand the notion of 'tools', as it seemed
like a distraction from what I was interested in. Given the centrality
of utilities, I think we should focus on 'utility' as the unit of site
management and avandon 'tools' entirely.
 
> 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.

In part. Simple utilities are very straight forward:

 - Add a utility -- it's an object, like content, but in a site mgmt
folder

 - Register it, making it available to the system

This is simple.

There are some utilities (I've not only stayed away from them, but
ripped them out of my working Zope configuration :) that are indeed
mysterious. But I dont see these ;)

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

Again, I'd rather see 'Utility Type' than tools. Even if there's a good
reason for another abstraction, it's worth the effort to figure out how
to avoid it.

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

This might be too big a conceptual change, but let me throw it out
anyway...

There's a correlation between Zope 3's software management scheme and
that of a typical package manager. Take RPM for example:

- Adding a utility to a site folder is analogous to downloading an RPM
package

- Adding and activating a registration is analogous to installing the
RPM package

- Deactivating a registration is analogous to uninstalling an RPM
package

- The tool type (hopefully called utility type) is analogous to the
'provides' concept in  RPM

We could shift the nomenclature away from registering toward installing.
I think users would definitely grok this providing it didn't get too
fancy. (I don't think the underlying architecture would need to change.)

 -- Garrett