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 )
