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

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?



Zope3-dev mailing list

Reply via email to