I'm not sure that "library" or "collection of libraries" is the right
term for what we want to be. I think we've been using it because it
stands in sharp contrast to "application", which, BTW, isn't exactly
what Zope 2 is. I think these terms were useful to make some points,
but neither is accurate. FWIW, I have a fairly open mind on this
topic. Lots of good points are being made. :)
On Oct 7, 2007, at 5:13 PM, Martijn Faassen wrote:
Jim Fulton wrote:
On Oct 7, 2007, at 6:25 AM, Lennart Regebro wrote:
I'm not entirely sure. I just observe that this doesn't seem to
be making much progress.
- We need a *realistic* (especially wrt available resources)
for managing releases. There are 2 aspects of this. We shouldn't
make plans for which there aren't enough resources. We also
shouldn't plan significant tasks that people won't care enough to
work on. I think the classic Zope 3.4 release is a good example
large effort that really wouldn't benefit many people, if any.
Do you have a sort explanation on what is the missing resource?
as it was for 3.3, lack of people-hours with knowledge in fixing the
I think it's one of the drawbacks of taking an ecosystem/libraries
approach instead of a application/framework style approach. An
application or framework typically is an integrated whole that has
a single version number. An ecosystem or set of libraries can be
integrated (which Zope 3 is) but everything evolves at different
rates and there's no single thing to install or talk about.
I'm not saying an ecosystem approach is bad, if that's what Zope 3
wants to be. I do think that such an approach needs to be
supplemented by a framework approach (and I've been putting work
into one way to do that).
If Zope 3 is an ecosystem, a "release" of Zope 3 the ecosystem
doesn't really make much sense. To follow the comparison with Linux
distribution, it's more like a "distribution" of an ecosystem. I'd
therefore suggest that the release of Zope 3.4, if it ever actually
happens, will be the last release of Zope 3 the application server
I hope that besides Grok, some community will stand up that takes a
less radical approach to building an application server on top of
the Zope 3 ecosystem. People having existing applications in Zope 3
to maintain (like myself with the Document Library) will have a
need for it, and Grok doesn't suit everyone's tastes anyway,
especially people comfortable with existing Zope 3 practices. As I
said elsewhere, I suggest we call this project not "Zope 3" but
something else, to avoid confusion with the Zope ecosystem (and
also to avoid implying it's the clear successor to Zope 2. I think
we can safely say by now that's not how history went).
Zope3-dev mailing list
Zope3-dev mailing list