Stephan Richter wrote:
On Sunday 07 October 2007 17:13, Martijn Faassen wrote:
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).
Why? I have no need for anything on top of Zope 3. I just need to have stable
sets of packages.=
Because we have endless confusion between Zope 3 the ecosystem and Zope
3 the web application framework. If you go and make a separate Zope 3
the web application framework and you can get away with just writing a
buildout.cfg, then be happy. Just call it something else, as otherwise
people will confuse it a lot with the exploded Zope 3 libraries. They
don't *have* to use this particular web framework in order to use Zope
3. They can also use Zope 2, or Grok.
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 don't understand that sentence.
If Zope 3 is like a linux distribution, we'll have to manage it like a
linux distribution does. A linux distribution has releases, but it
doesn't have releases of something individual you install and run. It
just has semi-frozen ecosystems being released once every while.
You can't do this and at the same time manage Zope 3 as an application,
I think. It's an either-or.
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
framework.
That would be really bad. Who defines stable sets then? Again, I think there
is absolutely no need for another framework on top of Zope 3.
The stable sets for the web application server are defined by those
people who develop the Zope 3 web application server. The people who
develop the web application server make choices that other users of Zope
3 technology might not make: perhaps to use Twisted for a web server.
Perhaps to use paste for configuration, or *not* use paste for
configuration. They might at some point decide that z3c.form is the
default form framework that is documented in Zope 3 tutorials, instead
of zc.formlib.
Hopefully the users of the Zope 3 technology can work together on
defining stable sets, but probably not for the entire range: Grok has
some extra dependencies that Zope 2 may not have, and vice versa, for
instance.
The Zope 3 web application server is not primarily what the Zope 3
project appears to be developing. I strongly suspect there are more
users of Zope 3 technology within the Plone community than outside it,
for instance. If the Zope 3 project cared about developing a web server,
you'd think it would do a somewhat better job presenting it to the
outside world on a web page, and that there'd be more people to actually
make releases?
Regards,
Martijn
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
