[Zope3-dev] Zope 3 Questions

[Shane Hathaway]

Jim Fulton wrote:
> Shane Hathaway wrote:
>> Say I set up a basic content management site.  Among other services, 
>> it sets up a view service.  Now say I want to add features to that 
>> site by installing packages into it.  Specifically, I want to install 
>> the package that replaces certain text areas with rich text widgets.
>>
>> When I install the rich text package, it does not replace the view 
>> service, instead it adds to the existing one.  Now I have a view 
>> service that's not specific to either content management or rich text 
>> editing, so it doesn't logically belong to any package anymore.   It 
>> belongs only
>> to the "active configuration".  Nearly every package will want to add 
>> to, but not replace, the views service.
>>
>> Does that map in some way to how Zope 3 packaging works?  I can't 
>> quite see it yet.
> 
> 
> I think the stubling block is the role of packages. Packages have two 
> roles:
> 
> 1. Distribution
> 
> 2. workspace
> 
> That is, some package, especially the default package, are there just to 
> provide
> a workplace for local configuration. Packages in service managers are a 
> bit like
> folders in content space.

Ok.  But look at what happens when I perform the installation steps I 
described above.  I see three alternatives:

1) The content management package sets its "views" service to be the 
active one, then the rich text package goes and finds whichever service 
happens to be active and adds its components there.  Now the rich text 
components are installed in the content management package, which isn't 
what the user intended.

2) Let's say instead that "active" components are managed entirely by 
some object outside the service (some kind of "component manager").  In 
order to find out what component to use, services always have to ask the 
component manager for a component.  So when the active "views" service 
needs to find the textarea view, it can't just use its own knowledge, 
since views might come from several packages.  It has to ask the 
component manager--another level of indirection.

3) The third alternative is for packages to "install" and "uninstall" 
components and configurations in the active services.  The user and the 
system have no awareness of packaging except when installing and 
uninstalling software.  In addition to their normal interface, services 
that can hold components implement a configuration interface.  The 
configuration interface allows installation/removal/querying of 
configuration directives and components.  Active services are not in any 
package, because they are not necessarily specific to any package.

When I was first developing the packaging ideas, I wrote a bunch of code 
using a variant of the first approach, then started to recognize its 
pitfalls.  Then I moved to the second approach, but came to realize that 
it complicates services and makes them hard to optimize.  Now I like the 
third approach a lot, especially since it follows the same patterns used 
by RPM, Debian packages, and other maturing software distribution 
systems.  In fact, /bin, /etc, /var, and /dev are a lot like services 
where you can install components.

You may be thinking along those lines already, or perhaps you have 
another way to mix components from multiple sources into a single service.

Shane