Monday, June 14, 2010

Zope 2.13 - alpha imminent

Dear world,

this is your Zope 2 release manager speaking. We had some discussion in the community about the roadmap ahead for the next Zope 2 release culminating in a plan today.

A first alpha release for Zope 2.13 will be released on June 25 - just over 10 days from now. More alpha releases will follow on a 3-4 weeks basis and a first beta will be out in early September. That is as usual without guarantees and subject to changes. A final release is expected later this year.

Zope 2.12 is continuing to be maintained. A Zope 2.12.7 bugfix release was released just yesterday.

Current Zope SVN trunk (which will become 2.13) is compatible with both CMF 2.2 and CMF trunk and the upcoming Plone 4. It is likely that Plone 4.1 will officially support Zope 2.13.

Zope 2.13 will bring a couple new features and has done a large deal of refactoring and house keeping. It currently only supports Python 2.6. Support for Python 2.7 might be added, if there is community volunteers to do the required work. Python 3.x support is out of the scope. Work has begun to port some of the underlying zope packages to Python 3.x, but there's still a lot more to do before this is feasible for Zope 2 itself.

So what's in it?

Zope 2.13 doesn't have any zope.app.* dependencies anymore. This finishes the transition from the hybrid Zope 2 + 3 codebase. Zope 3 itself has been split up into two projects, the underlying Zope Toolkit consisting of foundation libraries and the application server part. The application server part has been renamed BlueBream. Zope 2 only depends and ships with the Zope Toolkit now. Large parts of code inside Zope 2 and specifically Products.Five have been refactored to match this new reality. The goal is to finally remove the Five integration layer and make the Zope Toolkit a normal integral part of Zope 2.

Zope 2.13 comes with native WSGI support. First pioneered in the repoze.zope2 project, this capability finally found its way back into the core and obsoletes the externally managed project. With WSGI Zope 2 can natively talk to a variety of web servers and isn't restricted to its own ZServer anymore. It also opens up new possibilities for writing or reusing middleware in Zope 2 or factoring out capabilities into WSGI endware. It's expected that this new deployment model will over time become the default and the old ZServer implementation will be deprecated. There's no concrete timeline for this yet.

There's an ongoing effort to refactor Zope 2 into more independent modularized distributions. Zope 2.12 has already seen a lot of this, with the use of zope.* packages as individual distributions and the extraction of packages like Acquisition, DateTime or tempstorage to name a few. Zope 2.13 continues this trend and tries to externalize packages containing C extensions. In a not so distant future it should be possible to run a Zope 2 like environment without the ZMI and the corresponding code. This is part of the vision for Zope 2 to evolve into a more modern and maintainable codebase, while preserving a realistic gradual upgrade path for existing installations and projects based on it. The Zope 3 project has shown that a complete rewrite is no viable answer for a large class of existing software.

There's a large number of smaller features and improvements in the underlying libraries and Zope 2 itself. For example Zope 2.13 will ship with the new ZODB 3.10 version, which sports some noticeable performance improvements. The move to the latest version of the Zope Toolkit libraries makes integration of Zope community projects like z3c.form much easier.

After the rather long release periods of Zope 2.12 and 2.13 we expect to switch to a shorter release period of six to nine months for the upcoming 2.14, 2.15 and beyond releases.

Discussion of the Zope 2 core development takes place on the zope-dev mailing list. Feel free to engage, leave comments on this blog or contact me in private.

Your release manager,
Hanno

4 comments:

  1. Does this mean that you can use uWSGI (within Nginx) to talk directly to Zope?

    Has anybody attempted this with some benchmarks?

    ReplyDelete
  2. @peterbe: yes, it means you can use any WSGI server.

    Much has been said about benchmarks, see http://nichol.as/benchmark-of-python-web-servers and http://blog.ianbicking.org/2010/03/16/web-server-benchmarking-we-need for different takes on this.

    The only Zope specific benchmark I've seen is at http://lists.repoze.org/pipermail/repoze-dev/2007-September/000487.html

    Basically that benchmark suggests that pure performance of the WSGI server is irrelevant. Even for a most trivial view like the quickstart page all of paste, zope.server and cherrypy have roughly the same results. For any normal view actually doing some database lookups the time spent in the WSGI server is going to be tiny compared to the time actually doing the work.

    I'd follow Ian here and suggest to look for robustness in servers and care about performance in application code.

    ReplyDelete
  3. Indeed but when the "view" is very fast it does matter.

    Got some Django code that is wrapped in a middleware that checks one thing (if you're not logged in) and serves the rendered page from memcache. These are fast and in my server benchmarks changing from FastCGI to uWSGI changed 500+ request/sec to 1,700+

    Surprised that something basic as the quickstart page isn't more affected by a faster middle-tier server.

    ReplyDelete
  4. Zope2 is a full fledged application server and not a lightweight web framework. All the object publishing, automatic transaction handling, security machinery and so forth sum up to a couple thousand Python function invocations on every request. Those cause an overhead that is at least 1 ms in itself, likely even more.

    So even if your view doesn't do anything, you won't get more than 500 or at most 1000 requests / sec out of it. The couple nanoseconds spent in ZServer are irrelevant at this point.

    ReplyDelete