Jim Fulton wrote:
> 2. I think local configuration address use cases that most people  
> don't have but introduce complexity that I bet a lot of developers  
> trip over.

I think there are two cases where people typically deal with local 

* setting up local utilities (for authentication, the catalog, 
application-specific configuration storage + UI)

* writing tests that involve local utilities. (a more advanced case, but 
still quite common)

> 3. I think the right word here is "local registry".  I think the whole  
> concept should be labeled as advanced and we should discourage people  
> from even pondering it unless they have a strong use case, like  
> wanting to host multiple web sites with different configs in the same  
> application. :)

I don't think "hosting multiple web sites with different configs in the 
same application" is the only use case.

* the catalog. This can be done using a global component that somehow 
stuffs information in the ZODB, but there are no common patterns for 
this that people can follow, so local utilities are currently easier to use.

* often it is nice to have application configuration to have a user 
interface, so that end users can configure aspects of the application. 
This may be filling in an email address or customizing a template or 
adding a user, etc. Local utilities are a nice solution for this, even 
if there is just a single application installed.

> 4. I think we should step back (re)think how we handle the goals that  
> drive this.  If we do, we might  come up with something so different  
> that we'd make this discussion moot.

My goals are:

* I do care about local component configuration

* I'm a simple person and want to make my life easier

* I want to be able to write and test local utilities without having to 
depend on zope.site for my testing (right now I have a hacked up version 
  that I just copy and paste). An example of the hacked up version of 
site management is here:


And I'd like to put that code somewhere proper.

* I'd like to change the dependency structure so that a minor dependency 
on site management doesn't require a package to pull in zope.container 
(which pulls in quite a bit itself)



P.S. As of this point I'm dropping my proposal to rename anything to 
anything. Let's indeed focus on the wider discussion (as indicated by 
Roger and Jim)

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

Reply via email to