Jeff Shell on Zope 3 and how Zope 3 does ka-boom! ================================================= The Zope 3 buy-in ----------------- Jeff Shell is an old-timer with Zope but nowadays best known for his helpful answers to Zope newbie emails on the `Zope 3 users list`_. In an `interesting post of his`_ today, he writes about Zope's evolving development model and the framework's architecture:: Having developed on and for Zope for nearly ten years now, I can say that there is no such thing as "traditional zope development" :). There are a lot of ways to get things done. I think it's a testament to the architectures of both Zope 3 and SQLAlchemy that we've been able to do this latest project in this style - and with the cleanest application/business code we've ever had. But it took a lot of work and time and experience from prior engagements to filter out the parts of Zope 3 that we wanted, the parts that were crucial, and all of the fluff we could leave out. Once we got to that point (and started building up some new libraries and frameworks of our own), our experience with Zope 3 took a turn back towards the positive. Exploding (sic!) Zope 3 ----------------------- I think what Jeff describes here is the typical buy-in into a larger framework, and the positive return on investment afterwards -- at least when you use Zope 3 :). The post wasn't all about warm fuzzies, though. Zope could do a lot better on the buy-in:: With [Zope 3's] ZMI, I end up asking "is this the UI I want to deliver to my customer?" And the answer is rarely "yes!" I feel like I have to arm wrestle a lot more to turn off and hide features. I still don't really understand how the 'Add' menu works. This isn't a criticism of the ZMI skin. It just hasn't been a fit for any of our customers or applications, which makes it very hard to support. Fortunately, it's fairly easy to do away with. But it also feels very hard to migrate away from if that's where ones initial work is. This is why I'm really looking forward to `zc.buildout`, the egg-ifying of Zope, etc. I look forward to the day when it's much easier to build and re-destribute -- even if it's only internally -- a custom configuration that leaves unwanted bits behind. I think this is a big deal and too hope that we can "explode" Zope 3 into many eggs soon. Jim wants to do it for Zope 3.4, yay! Having smaller, more easily distributable Zope packages will also reduce the buy-in into Zope as a platform. For example, you won't *have* to ship with the ZMI anymore if you not only think it sucks but also find it disturbing to develop with. (Decoupling the ZMI will also grant one of SteveA's long standing wishes, by the way.) One Zope, indivisible? ---------------------- As you all might remember from a few months back, the explosion of Zope 3 to a pool of web develoment libraries also has a counterpart in the `Zope vision`_: There would only be one Zope application server. I know, the fronts where pretty hard back when he had the discussion. The Zope 3-only people didn't want to go back and have to deal with all the Zope 2 mess (I don't think they will have to, but...) and others like Martijn wanted to preserve the way we currently integrate Zope 2 and Zope 3. I still think exploding Zope 3 and converging towards one Zope app server (Zope 5?) is a good idea. The *reasons* why I think that have changed over the past few months though: * Zope 2 has lots of features that Zope 3 just doesn't have. Take the whole through-the-web development approach. Yes, I know it's icky to Zope 3-onlys. Heck, I found it icky a while back (and still do in a way). Recently, however, I had to do some consulting on a *large* Zope 2 app. I felt like back in 2002, collaborating with all other developers via through-the-web code. And you know what, it wasn't that bad. Jim had been preaching that we shouldn't ignore those Zope 2 use cases too much in the Zope world. Now I know what he meant. * Another of Jim's point was that Zope 2 has some features that are more mature than Zope 3's. I guess you could also find a few features where the opposite is the case. Just because certain things have been in production for ages doesn't mean they're mature (my mom always jokes that the longest lasting things built by my dad are also the ones made in a rough-and-ready way). Still, I'm now wondering: Is somebody actually going to improve the Zope 3 WebDAV implementation? I know that the one in Zope 2 works with lots of clients pretty well, the Zope 3 one doesn't even have ``LOCK``. Zope 2 has also had lots of love from Windows folks like the `Enfold people`_ and is probably be much better to operate on Windows than Zope 3 is. And then there's the ZCatalog which has lots more functionality and plug-ins in Zope 2 than in Zope 3. Do we really have to reimplement everything in Zope 3 just so that it can become what Zope 2 already is? Couldn't we just evolve Zope 2? * There is an increasing driving factor for Zope 3-style technology on Zope 2. Some Plone core developers are now pushing to use formlib, the i18n machinery, events, viewlets etc. Pretty soon we'll lots of innovation coming from projects like these. Where will this innovation be directived towards? Nuxeo and Infrae were pioneers among the ones who implemented stuff on top of Five. In two projects, they already used two different approaches. CPSMailAccess is in a lot of ways a Zope 2 and CMF application, but just uses as much components from Five as possible. The result is truly amazing, almost no dependencies on CPS. With CPSSharedCalendar, they went a different way, building from the ground up: CalCore is a pure Python library, CalZope pure Zope 2 and CPSSharedCalendar does the integration into the portal, again, with lots of Zope 3 in mind. The Plone people go yet another way: a lot of stuff they build they want to make work on pure Zope 3, only the UI should be a thin layer geared towards Plone. Many different approaches to cope with the current situation - Can't there be a common direction for Zope technology? * As I'm writing on the `new edition of my book`_, I find that lots of things I document are already available in Zope 2 one to one already. I think compared to a few months back we now have a better understanding of what kind of Zope 3 technology the Zope 2 folks need. Given that knowledge I think it'd be much better if we bundled our efforts. Both Zopes, for example, want a decent local component customization story (and it seems the CPS and Plone guys now want it badly). Why maintain two systems? * We're about to witness a small desaster regarding our new time-based release schedule. We're dropping behind schedule badly. It might be because no one seems to care that much about new releases. I think it's mostly because we don't have the resources (see above on bundling them). We've also had a lot of negative comments on time based releases. I suspect what people are most worried about is that there are so many releases happening in such a short time. It's probably more a psychological effect than anything else. Point is, if we had an exploded Zope 3 with each project (zope.component, zope.interface, etc.) on its own release cycle, the main Zope release cycle could be much more relaxed. Perhaps we wouldn't *need* a major Zope (the app server) release every 6 months. Perhaps 8 or 12 months would suffice, if you can still get certain new features in with newer versions of the zope.* packages. Philipp tired. Philipp sleep. ----------------------------- I've now successfully drifted off so far, I won't try to close the circle with Jeff's email now, as I'm getting a bit tired here :). The bottom line is that the co-evolution of Zope 2 and Zope 3, as nice as the benefits are currently, will require us to rethink our strategy. Lots of groups within the community have needs or will grow needs that the current system cannot handle. No matter whether that's Jeff with his ZMI or Plone's evolvement towards local component management. .. _Zope 3 users list: http://news.gmane.org/gmane.comp.web.zope.zope3.user .. _interesting post of his: http://mail.zope.org/pipermail/zope3-users/2006-August/004053.html .. _Zope vision: http://mail.zope.org/pipermail/zope3-dev/2006-February/018415.html .. _new edition of my book: http://worldcookery.com/News/Grapevine .. _Enfold people: http://www.enfoldsystems.com/