Hanno Schlichting wrote:
> On Thu, Apr 1, 2010 at 3:49 AM, Martin Aspeli<optilude+li...@gmail.com>
>> What's the next step? I'd love to see some roadmapping ala that you did
>> for Plone 5, in particular to discuss our WSGI story (which I'm
>> interested in helping out with if others can help too).
> There's no big roadmap yet, but I have some ideas :)
> In general I'd like to avoid a major Zope release, that isn't used by
> an official Plone release. Zope 2.11 hasn't seen much attention and we
> had to maintain 2.10 anyways. But if there's a decent and stable
> feature set that other consumers like to get there hands on, we can
> get them a release. I just won't be pushing into that direction.
> Here's what I can see today:
> There's a bunch of stuff already done as noted in
> - zope.app removal
> This project is all finished. Zope2 doesn't contain any trace of
> zope.app or the name Zope 3 in itself nor its dependencies anymore.
> - Moving formlib out of the core
> Triggered by the above and finished as well. Zope trunk doesn't
> contain any trace of formlib anymore. The relevant code is now in the
> five.formlib package. This package is also included in Zope 2.12, so
> you can start using the functionality and be compatible with both Zope
> versions. CMF does this already.
> - WSGI
> I cannot tell at the moment. It's going to depend on the actual
> changes required to get this to work. Since there is some broken WSGI
> support inside the 2.12 codebase, we can claim a certain deal of
> changes as bugfixes. But there's limits to what we can warrant as a
> bugfix. If the code changes are self-contained and only touch the
> broken WSGI modules, we are good. If we require changes all over the
> board for whatever reasons, this will have to be a new feature and go
> into Zope 2.13. Only a branch with actual code will tell :)
It'd be interesting to see what comes out of the PSU sprint Tres talked
about. I have an interest in this, so will be happy to help, though I'll
not be able to drive it entirely.
> - ZTK
> As long as there's no formal release of the ZTK or a defined and
> stable process around it, Zope 2 defines its own KGS. It so happens to
> use exactly the same versions as the current ZTK trunk. Once we are
> making progress on the ZTK release, we'll see how Zope 2 can use such
> a release. My current guess is that Zope 2.13 will use some ZTK 1.1
+1 - I think there's a big win from this. I also hope we can squash all
the "what is the ZTK" debates. At the end, it feels like a lot of
> - Five deprecation
> I did a whole bunch of work on this already and keep working on it.
> The end goal is to be able to deprecate the entire Products.Five and
> phase it out of the core. Actually useful functionality in it, is
> integrated into the proper places inside the Zope2 core packages
> instead. Like security stuff in AccessControl, container events in
> OFS, reading site.zcml and setting up the CA in Zope2/App and so
> forth. There's a number of hard cases, where there's some semantic
> differences between zope.* packages and their Five equivalent,
> especially in the "browser" realm. This project might not be
> completely finished for 2.13. And yes, there's some difficult
> questions with non-obvious answers around this. We'll deal with them
> once we get there. I'm focussing on the obvious parts first.
+1 - sounds hairy, though.
Getting rid of the Zope 2 specific ViewPageTemplateFile and BrowserView
(already done, I guess) would be a good starting point.
> - Reduce C code in Zope 2
> My first part of this was discussed and implemented. The remaining C
> code inside the Zope 2 distribution is in AccessControl,
> DocumentTemplate and ZCTextIndex. We'll see what to do about them,
> once their packages are actually self-contained.
I'd also like a more sane/documented/debuggable AccessControl. Sigh.
> - Make Zope 2 more modular
> This is related to the above two points. I'm not quite sure about the
> details of the implementation yet. But in general it would be nice, if
> a consumer of Zope 2 could use it's core, without getting a whole
> bunch of stuff it doesn't want. The obvious example here is Plone,
> which continues to use less and less code from Zope 2, but has no
> chance of making a radical cut and loose it all. There's interesting
> problems, like being able to use Zope 2 without the ZMI. In some sense
> this is similar to using the ZTK instead of zope.app. The only thing I
> know for sure, is that I'd like to first make the packages inside Zope
> 2 standalone and reusable and only once they are, break them into more
> distributions. We've gone the other way around with Zope 3 and it has
> cost a whole lot of pain.
I think it may help to make a list of the things we'd like to be able to
get rid of, and then isolate those.
> - ZODB 3.10
> Jim promised a second alpha release to be out shortly. Should be low
> risk to upgrade to it. The multi-threaded ZEO server promises some
> good improvements.
> - Python 2.7
> This would be 2.7 support in addition to the existing 2.6. Last time I
> checked all Zope 2 tests passed. But there where some hairy looking
> test failures in zope.proxy and some more in RestrictedPython.
> RestrictedPython will also need a new security review to make sure it
> continues to work with 2.7.
> - Python 3.x
> Not on the agenda. We'll need to tackle this on the ZTK level first.
Personally, I think this is too unrealistic right now to expend much
energy on. I don't see any good reasons right now to try to move to
> For an actual timeline, it seems autumn this year is the earliest any
> 2.13 could come out, so it properly supports Python 2.7 and we have
> something definitive on the ZTK matter. But I'm not going to rush this
> and it's somewhat more likely we'll end up with an ever later release
> and match the Plone 5 release schedule.
One thing that would be interesting from a Plone perspective is whether
people could optionally use Zope 2.13 with Plone 4.x. That may be quite
attractive if Zope 2.13 has WSGI.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -