[Zope-dev] RFC: Site -> Locus

[Martijn Faassen]

Hi there,

We have a concept of "Site" in the Zope Toolkit, along with SiteManager 
and the like. What this concept allows us to do is locally register 
components. Most typically this is used for local utilities such as a 
catalog.

During traversal, a thread-local is set with the current site, so that 
code that looks up a compoment will check the current site(s) before 
falling back on the global component registry.

The word "site" has bothered myself and others for some time. It doesn't 
really have the right connotations for random programmers; when you hear 
site you think about website, and that's not really what this implies. 
The reason we called it site I think has to do with the idea that we 
expected Zope-based web sites to be applications with a lot of local 
components.

I'm interested in refactoring zope.site to split it into two packages: 
one that has the pure site-based logic with minimal dependencies, and 
support to easily test with sites, and the other with dependencies on 
zope.container. While thinking about this, I figured this might be a 
good opportunity to rename the word 'site' to something better.

I propose we use the word 'Locus' instead of 'Site'. This word doesn't 
have a lot of connotations in the web programming world, and people can 
guess by simply looking at the word it might have something to do with 
*local* components. It's also short. It's also a synonym of the word 
site. The dictionary says: "a place, a locality" and "the scene of any 
event or action". I think that works quite well.

Two possible options for moving forward with this:

* create a zope.locus package that contains the core locus support. It 
only speaks in terms of "locus" and doesn't use the word "site"

* zope.locuscontainer will have the container support surrounding sites.

* zope.site becomes a backwards compatible but deprecated package that 
does 'from .. import .. as' to keep 'getSite' and 'setSite' and such 
around. The package itself will be deprecated and people will be 
encouraged to depend on zope.locus (or zope.locuscontainer, but that 
will be rare).

The other plan:

* we fold the locus support into zope.component. This is assuming that 
the dependencies for Locus can be kept to a bare minimum (no ZODB 
dependencies either).

* we add the LocusContainer support to zope.container directly; since it 
already uses zope.component this isn't a problem

* zope.site is still a backwards compatible package (that depends on 
zope.container and zope.component, which it already does).

The second plan is my favorite if it is possible dependency-wise and 
zope.component doesn't take on new dependencies. I think support for 
local components could very well be part of zope.component conceptually. 
It would allow us to eliminate one package (zope.site) without 
introducing any new packages (the other plan increases the amount of 
packages by one, trading zope.site for zope.locuscontainer).

What do people think about:

* the idea of renaming Site to Locus

* the plan for refactoring?

Regards,

Martijn