On Apr 14, 2009, at 11:20 AM, Martijn Faassen wrote: > Hey, > > Jim Fulton wrote: > >> What the heck is the "Zope Toolkit"? Is there a page somewhere that >> defines what it is? > > http://docs.zope.org/zopetoolkit/about/index.html > >> I thought Zope 3 was being renamed "Zope >> Toolkit", but given recent discussions, I'm not sure. > > That never was the idea. The idea was to separate the concept of the > toolkit from the concept of "Zope 3". Zope 3 (if people want to > maintain > it) is a user of the Zope Toolkit just like the other users. The Zope > Toolkit inherits its libraries from Zope 3 but is trying to take on a > lot less code. > > The goal is to take on *less* of a burden to maintain than the full > Zope > 3, and to move a bit faster than we have been. > > The Zope Toolkit is a project that: > > * aims at maintaining and releasing the various Zope libraries > > * aims at supporting the projects that some of use these libraries > individually (repoze, bfg, twisted) > > * aims at supporting the projects that use most of these libraries > as a > set (Grok, Zope 2, Zope 3). > > * doesn't include the ZMI bits
I don't think these "bits" are cleanly separated. For example, if a content component has some views, are those ZMI bits? Can you identify projects that are in or out of the toolkit? What about zope.publisher? zope.security? zope.app.publication? > * won't have a way to install it (but Grok and Zope 2 and Zope 3 might > come to share a large part of the installation method) > > * will try to shrink the codebase as much as it will try to grow it. > To > this effect the refactoring efforts, with the aim to throw out > libraries > (from the toolkit, not from the universe of packages) quite > aggressively. Hopefully much of zope.app.* can go, as the useful non- > ZMI > bits get salvaged. > > The Zope Toolkit is *not* like Zope 3 in an important sense: there's > no > attempt to provide information about how to install it and start > developing with it. We'll have this information for the individual > libraries in the tookit, and for Zope 2 and Grok and so on, but not > for > the Zope Toolkit itself. 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. 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. Jim -- Jim Fulton Zope Corporation _______________________________________________ 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 )