Hanno Schlichting wrote: > On Thu, Apr 1, 2010 at 3:49 AM, Martin Aspeli<optilude+li...@gmail.com> > wrote: >> 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 > http://svn.zope.org/Zope/trunk/doc/CHANGES.rst?view=markup. > > - 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.
Cool. > - 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. Cool. > - 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 > release. +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 bike-shedding. > - 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. +1 > - 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. +1 > - 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 Python 3. > 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. Martin -- 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 https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )