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