Jim Fulton wrote:
> I don't think these "bits" are cleanly separated.  For example, if a  
> content component has some views, are those ZMI bits?

Yes. zope.container doesn't define views. zope.app.container did (and 
does). "browser" directories are generally not part of the Zope Toolkit, 
though there are some exceptions (zope.app.publisher.browser, 

> Can you identify projects that are in or out of the toolkit?  What  
> about zope.publisher? zope.security? zope.app.publication?

Currently all three are in.

zope.publisher + zope.app.publication might not remain in permanently if 
a better way of doing things evolves, but that's up in the air right now.

> I agree with the idea of simply supporting a library of components.   
> I'm uncomfortable with the idea of saying you're going to "shrink the  
> codebase" without saying what's going.  

The ZMI is the bit that is going right now. Since we're factoring 
non-ZMI bits out of zope.app.*, eventually that'll mean a whole range of 
zope.app.* packages will not be maintained by the Zope Toolkit 
developers. The other bits are up for discussion.

We don't intend to stop people from maintaining other packages outside 
the toolkit.

> I don't want to see a separate  
> "Zope 3 " project distinct from the "Zope Toolkit". 
> I do want to see  
> the components we're using live within a project.  If the "Zope  
> Toolkit" doesn't include components in common use, then I don't think  
> it has a lot of value.

I'm not in the business of maintaining Zope 3 myself; I mainly care 
about how Grok uses it, and how I can integrate libraries in the 
ecosystem into my apps.

The Zope Toolkit includes components in common use by Grok, Zope 2, and 
Zope 3.

The Zope 3 project always attempted to be far more than just being a 
bunch of libraries. It attempted to be a system you can install and find 
documentation for and start developing with. When you install it, you 
see a user interface. It had a group of people who cared about it that 
you could talk to. There are a lot of concepts associated with Zope 3.

What I'm trying to do is to separate these concepts, which is why we're 
going through some confusion.

The Zope Toolkit is something that doesn't have an installation story 
for the whole. It does have some documentation about the whole: how it 
is developed primarily. But instead of having documentation for the 
whole ("Build your app with the Zope Toolkit, here's how to get 
started!" is not going to be there), it will focus on documentation 
about how to use the individual libraries. It leaves how to use it as an 
integrated whole to other projects. The Zope Toolkit has implementations 
of content objects such as the container. It doesn't have a user 
interface; it just has a way to construct user interfaces.

The Zope Toolkit is there to serve the people who use it. That's people 
who use a large range of these libraries, or just some of them, and 
projects that build on top of these libraries.

The question at hand is whether people care about a project that 
presents itself as a "whole", uses a lot of the Zope Toolkit, and has an 
installation story (and possibly a user interface), and that isn't Grok 
or Zope 2, but like Zope 3. If so, we could have a Zope 3 project that 
cares about those things (naming discussion aside).



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