On Monday 08 October 2007 06:56, Martijn Faassen wrote:
> Because we have endless confusion between Zope 3 the ecosystem and Zope
> 3 the web application framework.
For me it is exactly the same. Zope 3 is a Web application server. Zope 2 uses
many components of the Zope 3 Web application server.
> 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.
But I consider the crafted set of libraries the "Zope 3 application server".
Whether you use just some of its components, choose a different WSGI server,
or exchange functionality is totally irrelevant; it just proves how good the
Zope 3 application server is.
> 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.
Right, and I think this is what we need to do for Zope 3. This is what
download.zope.org/zope3.4 and the KGS idea is all about.
> You can't do this and at the same time manage Zope 3 as an application,
> I think. It's an either-or.
I have never defended the idea of a Zope 3 application. In fact, a lot of my
efforts in Zope 3 right now are to get rid of the ZMI in my projects.
application server != application
> 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.
Thus, the KGS should include all packages the sub-communities care about. For
example download.zope.org/zope3.4 has both z3c.form and zope.formlib. Again,
we should look at Linux distributions. They have a very healthy process for
including and excluding packages. The community makes requests of packages to
be included, then they are tested and if all is well, they are added to the
next version of the distribution. If a package looses support and becomes so
outdated that it does not work with the latest set of packages anymore, it is
> 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
Well, I would like to have a KGS that can be used by all user projects,
including Zope 2 and Grok. If any of the user projects want to nail
additional versions, they can do so and I would be glad helping to develop
technology to make this happen.
> 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?
I think we have very different definitions of application server. For me web
server != application server. In Zope 3's case I could care less what the Web
server is. For me, the publisher is really the server component.
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
Zope3-dev mailing list