Hey, 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, zope.app.form.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. [snip] > 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). Regards, Martijn _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )