Zope Summit, DZUG, repoze.bfg

I've spent a thought-provoking week in Germany, primarily in the company of people from the greater Zope community in Europe. By "the greater Zope community," I mean projects such as Plone, Zope 2/CMF, the Zope Toolkit, Grok, and BlueBream.

My week started in Halle, Germany, at Gocept's offices in a meeting called a "Zope Summit." 19 people gathered to try and figure out what we could collaborate on, how we could do it, and where things went from here. There was not a single answer to which everyone agreed. Some of the participants had heated words. By and large it was very friendly, though.

From my perspective, the only clear points of collaboration for us now are WSGI and libraries from the Zope Toolkit. Using WebOb would also give us more opportunities. Jim Fulton said he had began work on that integration over a year ago.

The most-discussed next step for people from the Zope community is repoze.bfg, also called BFG--a project with at least some measure of Zope heritage, but no direct representation in the meeting other than Charlie Clark's advocacy (see his EuroPython 2010 presentation and some of my previous blog posts).

In regards to BFG, I was pleasantly surprised to hear two pieces of news from Charlie. First, the next version of Pylons is slated to build on top of repoze.bfg. That's great news for the huge effort that Chris McDonough, BFG's lead developer, has put into this consolidation and the framework itself. It's also good news generally for sharing and collaboration in Python web frameworks: BFG, Pylons, and TurboGears will now all be interconnected, each building on the previous one, and all of them using WebOb and WSGI beneath.

Second, Tres Seaver, Chris McDonough, and others, are working on a layer above BFG for building content managing systems. While I strongly suspect that it would be years for this to compete feature-wise with longstanding efforts like Plone, a lighter-weight BFG-based CMS that could be customized much more easily would probably be immediately compelling for certain use cases.

After the Zope Summit, we moved Tuesday evening from Halle to Dresden, for the DZUG (German Zope User Group) conference starting the next day. The health of the German Zope community was startling to me. In America, the name "Zope" is often cause for many Python programmers to dismiss ideas and libraries, or look at them with prejudice. Here, developers acknowledge failings and are looking to the future, but the conference has a strength and positiveness that is a stark contrast to the attitude to which I have become accustomed.

That said, the conference, like the summit, was also a time of evaluation of where the Zope community is now, and where it might go soon. BFG was again a central topic in the meeting rooms and over meals, and the subject of a couple of presentations. BFG got positive notice, though some expressed a desire to see a clear path for more functionality, such as user management.

The first conference day started with Jim Fulton, the original Zope leader (or "Zope Pope," as he was called) talking a few minutes about his perspective on where Zope came from and where it is now. I interpreted it as a farewell, and certainly a repetition of the fact that he is no longer the Zope leader. Beyond that, he talked about mistakes made in the Zope project, and strengths and lessons to keep in mind for the future. A central opinion he stated was that Zope's problems came in part because it tried to be two things at once: a CMS and a framework for Python developers. He advised against making that kind of mistake in the future.

That evening I presented a keynote titled "Launchpad and Zope." It was a set of five loosely connected lightning talks, using a clever PyGame program fellow-Canonicalite Benji York wrote. It was very well received, and I had a lot of fun. Putting the slides up might be a little tricky because of the custom format, with movie integration, but maybe I'll try to put them up. These were the topics, with a short summary for each.

Launchpad and Zope

The Launchpad project aims to connect the open source community together, and particularly to connect Ubuntu developers, packagers, and users within it. It uses several key Zope Toolkit libraries, especially templating, publishing, security, interfaces, and the component architecture.

Launchpad's webservice

Launchpad's webservice is easy to use and exposes an amazing amount of Launchpad's functionality.

Open Source Libraries

Launchpad has a number of open-sourced libraries, such as lazr.restful, wadllib, lazr.resftfulclient, lazr.config, lazr.batchnavigator, lazr.uri, and lazr.delegates.

Buildout and System Pythons

The Buildout 1.5.X line introduced some nice features to make Buildout usable with exposed system Python libraries.

Launchpad and Zope?

Launchpad's use of Zope has some downsides and some upsides. We plan to keep some libraries because of their usefulness, but would like to remove others, such as Zope's publisher, because of complexity.

The other presentations were pretty much all in German, and I don't understand German well enough for a technical talk. One other was in English, but was about Plone, with which I have little practical connection or interest other than wishing Plone well.

While I was at the conference and the summit, I also spent time discussing interesting topics with attendees in the shared areas. Here are some representative summaries.

Chameleon

Launchpad is interested in using Chameleon, and had some work done over a year ago in that direction. I talked about some of the problems I had encountered and got some hints on next steps. I also learned that it was not yet in production for one of the people promoting it; and got confirmation that the maintainer is working on a rewrite. These last two items concerned me.

zope.security

Volker Jaenisch brought up some concerns about the zope.security package. After discussing with him, we ended up with these observations and recommendations.

• emphasize in zope.security that __parent__ *must* be set in order for expected behavior to occur. (Recommendation: use a factory?)
• z3c.form: document that security is not ready until after addition.
• zope.security: design a cache to be held over multiple requests? Can be a big performance win, but must be very careful.
• zope.security: document that cache has potential edge cases
  • as long as cache is maintained, moving an object needs to either completely or partially clear the cache
  • similarly, children of moved objects must have their cached security values invalidated
  • would be nice to have a policy that did not have cache
• zope.security: would be nice if invalidations after grants and other security changes were localized (currently global)
• zope.security: would be better if the test showed integration between the policy and the proxy unauthorized

ZODB/ZEORAID

Christian Theune and I talked about the ZODB for a while, and he described some of the advantages and upcoming work on ZEORAID.

Django DB connections

Marc-André Lemburg showed me some interesting code he has to generate code to interact with the database, and we looked into how Django controls its Database connections.

It's been a nice week. The people at the conference and the summit were great to be around, and I particularly appreciate all the work from Gocept to organize these events. I'm also honored to have been invited as a keynote speaker.

And I'll be glad to be home. :-)