[Zope3-dev] Local site configuration is too hard

[Roger Ineichen]

Hi Garrett

Behalf Of Garrett Smith
> Sent: Monday, February 21, 2005 5:54 PM
> To: jim at zope.com; zope3-dev at zope.org
> Subject: RE: [Zope3-dev] Local site configuration is too hard
> 
> 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

I think that's a good idea.
but...
Let's say we have a openoffice as a utility. There are more ways
to activate the openoffice.

Let's say somebody like to use just the writer part and others like
install the openoffice at all.

I think here we need some predefined configuration 'set'
instead of 'if you don't activate all, do it by yourself'

I would say there is a difference or one more step in install
and configure. In one of this steps we have to find out why or 
for what (providing) the utility should be registred or activated.

Let's say we have to configure our utilities. This is analogous 
to if you configure a LDAP server. The installation process
is just simple, but we have to configure the .conf file.
But configureing a .conf file is defently not the part what 
users can do. We have to offer some pre-configured software.

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

btw;
I like your simply description.

Regards
Roger Ineichen

>  -- Garrett
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev at zope.org
> Unsub: 
> http://mail.zope.org/mailman/options/zope3-dev/dev%40projekt01.ch
> 
>