Re: [Zope-dev] Zope 2.13 roadmap
On Thu, Apr 1, 2010 at 3:49 AM, Martin Aspeli <optilude+lists@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. - 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 :) - 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. - 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. - 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. - 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. - 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. 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. All that said, we'll change plans if something comes up and a better plan suggests itself. The above list is obviously non-exclusive, so if someone else has anything he wants to work on, announce it, discuss it and we'll decide when and how it gets in. Cheers, Hanno
Hanno Schlichting wrote:
On Thu, Apr 1, 2010 at 3:49 AM, Martin Aspeli<optilude+lists@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
On Thu, Apr 1, 2010 at 9:33 AM, Martin Aspeli <optilude+lists@gmail.com> wrote:
Hanno Schlichting wrote:
- Five deprecation
+1 - sounds hairy, though.
Getting rid of the Zope 2 specific ViewPageTemplateFile and BrowserView (already done, I guess) would be a good starting point.
With Zope 2.12 BrowserView is basically done. You can now import the BrowserView class from zope.publisher.browser instead of the one from Five. But ZCML directives still use the Five class, to ensure code using fancy Acquisition magic continues to work. ViewPageTemplateFile is a very different beast. The page template machinery of Zope2 and zope.tal are different enough, that there's no easy upgrade path. The expression context ("here", "modules", ...), path traversal, restricted templates, ... there's enough subtle differences all over. I think it is more likely that applications like Plone will switch to Chameleon and adjust import paths to a chameleon specific package.
- Make Zope 2 more modular
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.
I'd kind of like to be able to explicitly decide what to get and make this an opt-in. I could see someone using AccessControl, OFS, Zope2 (for the application bootstrapping) and ZPublisher without much of anything else, except their "dependencies" like Acquisition or tiny packages like Globals, Lifetime and Signals. Such a minimal set wouldn't be called Zope 2 anymore, as Zope 2 is the application server with all the TTW capabilities, Python scripts, ZRDB and friends. But only actually looking at the code and refactoring it will tell to what extend this is possible. My first step is to attack Five, as its been pulled in by everyone and was dependent on everything in return. Once we untied that knot, we can see what is going to be possible.
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.
This is speculation at the moment. If WSGI ends up in 2.13 without a backport to 2.12, we can look at it. One option is for someone to backport the changes into a standalone package, like repoze.zope2 and allow people to pull it in as an experimental backport. If only some people will want to use it, this is a very viable option and much like the status quo of repoze.zope2 today. Hanno
Am 01.04.2010, 15:30 Uhr, schrieb Hanno Schlichting <hanno@hannosch.eu>:
With Zope 2.12 BrowserView is basically done. You can now import the BrowserView class from zope.publisher.browser instead of the one from Five. But ZCML directives still use the Five class, to ensure code using fancy Acquisition magic continues to work.
So, if I don't need any of the acquisition I just go with zope.publisher.browser? How about the configuration? Just use the adapter directive?
ViewPageTemplateFile is a very different beast. The page template machinery of Zope2 and zope.tal are different enough, that there's no easy upgrade path. The expression context ("here", "modules", ...), path traversal, restricted templates, ... there's enough subtle differences all over. I think it is more likely that applications like Plone will switch to Chameleon and adjust import paths to a chameleon specific package.
I think this is you speaking with different hats on. My view on Zope2's roadmap would be to continue to move towards the zope.tales implementation, deprecating as necessary. I don't see any difference between Zope2 and Plone as to whether the actual implementation is zope.tales or Chameleon. Replacing "here" with "context" in templates is easy enough. That said, I did get pretty scared when I looked at the implementation! Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
On Thu, Apr 1, 2010 at 3:50 PM, Charlie Clark <charlie.clark@clark-consulting.eu> wrote:
Am 01.04.2010, 15:30 Uhr, schrieb Hanno Schlichting <hanno@hannosch.eu>:
With Zope 2.12 BrowserView is basically done. You can now import the BrowserView class from zope.publisher.browser instead of the one from Five. But ZCML directives still use the Five class, to ensure code using fancy Acquisition magic continues to work.
So, if I don't need any of the acquisition I just go with zope.publisher.browser? How about the configuration? Just use the adapter directive?
The class you get from any ZCML directive is going to be the one from Five using the Five.bbb.AcquisitionBBB mix-in. It emulates enough of Acquisition without actually using it. You cannot opt-out of that bit of bbb support for the ZCML directives. At some stage it might make sense to allow this. But I'd only consider this if you could opt-out of all Five specific features for all browser directives at once. For now the little bit of extra mix-in doesn't hurt much and you'll hardly ever notice it. The change is described at http://docs.zope.org/zope2/releases/2.12/WHATSNEW.html#acquisition-redux
ViewPageTemplateFile is a very different beast. The page template machinery of Zope2 and zope.tal are different enough, that there's no easy upgrade path. The expression context ("here", "modules", ...), path traversal, restricted templates, ... there's enough subtle differences all over. I think it is more likely that applications like Plone will switch to Chameleon and adjust import paths to a chameleon specific package.
I think this is you speaking with different hats on. My view on Zope2's roadmap would be to continue to move towards the zope.tales implementation, deprecating as necessary. I don't see any difference between Zope2 and Plone as to whether the actual implementation is zope.tales or Chameleon. Replacing "here" with "context" in templates is easy enough. That said, I did get pretty scared when I looked at the implementation!
"here" vs. "context" is the most trivial of the differences and one could make that change. Since the two are simple aliases, it's easy and only tedious to do the switch. On its own it doesn't have much benefit though. But it's all the other things which are hard. For example there's no "restricted page template" story outside Zope 2. There's nothing to move to, except you decide to drop the support of this particular feature. But that's not something that is sensible to do for Zope 2. An application like Plone can make the decision to stop supporting TTW development in the long run. For Zope 2 that doesn't make any sense, as TTW development is what makes it Zope 2. But my view on what makes sense for Zope 2 might always be biased as I noted :) Hanno
Am 01.04.2010, 16:11 Uhr, schrieb Hanno Schlichting <hanno@hannosch.eu>:
The class you get from any ZCML directive is going to be the one from Five using the Five.bbb.AcquisitionBBB mix-in. It emulates enough of Acquisition without actually using it. You cannot opt-out of that bit of bbb support for the ZCML directives. At some stage it might make sense to allow this. But I'd only consider this if you could opt-out of all Five specific features for all browser directives at once. For now the little bit of extra mix-in doesn't hurt much and you'll hardly ever notice it. The change is described at http://docs.zope.org/zope2/releases/2.12/WHATSNEW.html#acquisition-redux
Thanks for the link. If legacy is as lightweight as with formlib then no problem at all.
"here" vs. "context" is the most trivial of the differences and one could make that change. Since the two are simple aliases, it's easy and only tedious to do the switch. On its own it doesn't have much benefit though. But it's all the other things which are hard. For example there's no "restricted page template" story outside Zope 2. There's nothing to move to, except you decide to drop the support of this particular feature. But that's not something that is sensible to do for Zope 2. An application like Plone can make the decision to stop supporting TTW development in the long run. For Zope 2 that doesn't make any sense, as TTW development is what makes it Zope 2.
I must say how impressed I was at how easy it was to migrate my various small projects to 2.12. TTW is still required for legacy but I wonder how much of it is still out there? Any chance of splitting it out? *ducks* knowing that someone is going to unleash the CMF's unbeatable "custom" skin argument. ;-)
But my view on what makes sense for Zope 2 might always be biased as I noted
Which is what the discussion is for and thanks for getting it stared. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
Hanno Schlichting wrote:
On Thu, Apr 1, 2010 at 9:33 AM, Martin Aspeli<optilude+lists@gmail.com> wrote:
Hanno Schlichting wrote:
- Five deprecation +1 - sounds hairy, though.
Getting rid of the Zope 2 specific ViewPageTemplateFile and BrowserView (already done, I guess) would be a good starting point.
With Zope 2.12 BrowserView is basically done. You can now import the BrowserView class from zope.publisher.browser instead of the one from Five. But ZCML directives still use the Five class, to ensure code using fancy Acquisition magic continues to work.
Right. That's pretty unobtrusive, though, and doesn't stop you from writing views that work in other Zope scenarios.
ViewPageTemplateFile is a very different beast. The page template machinery of Zope2 and zope.tal are different enough, that there's no easy upgrade path. The expression context ("here", "modules", ...), path traversal, restricted templates, ... there's enough subtle differences all over. I think it is more likely that applications like Plone will switch to Chameleon and adjust import paths to a chameleon specific package.
That's probably a better solution, although I'd really like to be able to write packages that use page templates that are not tied to Zope 2, Five, Plone or, ideally, Chameleon, at least not unless everyone else (Grok, Blue Bream, thus the ZTK) switched to Chameleon and deprecated zope.pagetemplate.
- Make Zope 2 more modular 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.
I'd kind of like to be able to explicitly decide what to get and make this an opt-in. I could see someone using AccessControl, OFS, Zope2 (for the application bootstrapping) and ZPublisher without much of anything else, except their "dependencies" like Acquisition or tiny packages like Globals, Lifetime and Signals. Such a minimal set wouldn't be called Zope 2 anymore, as Zope 2 is the application server with all the TTW capabilities, Python scripts, ZRDB and friends. But only actually looking at the code and refactoring it will tell to what extend this is possible. My first step is to attack Five, as its been pulled in by everyone and was dependent on everything in return. Once we untied that knot, we can see what is going to be possible.
Good plan.
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.
This is speculation at the moment. If WSGI ends up in 2.13 without a backport to 2.12, we can look at it. One option is for someone to backport the changes into a standalone package, like repoze.zope2 and allow people to pull it in as an experimental backport. If only some people will want to use it, this is a very viable option and much like the status quo of repoze.zope2 today.
Indeed, I just don't want to end up with the kind of inevitable bitrot that something as complicated and compatible as repoze.zope2 ended up with. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book
On Thu, Apr 01, 2010 at 05:41:17AM +0200, Hanno Schlichting wrote:
There's no big roadmap yet, but I have some ideas :) <snip> All that said, we'll change plans if something comes up and a better plan suggests itself. The above list is obviously non-exclusive, so if someone else has anything he wants to work on, announce it, discuss it and we'll decide when and how it gets in.
I don't think I'll be able to work on it, but I think it's worth consideration: Unicode issues with Zope 2.12. I've seen these on at least three different Zope 2 sites built with a combination of TTW page templates, Python scripts and (sometimes) DTML documents: things like title attributes store their data as UTF-8 strings, while page templates insist on Unicode objects, resulting in errors all over the place. Those sites worked with Zope 2.9 and broke down after an upgrade to 2.12. That's a not very nice thing to do to your users... Regards, Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
On Thu, Apr 1, 2010 at 11:52 AM, Marius Gedminas <marius@gedmin.as> wrote:
I don't think I'll be able to work on it, but I think it's worth consideration: Unicode issues with Zope 2.12. I've seen these on at least three different Zope 2 sites built with a combination of TTW page templates, Python scripts and (sometimes) DTML documents: things like title attributes store their data as UTF-8 strings, while page templates insist on Unicode objects, resulting in errors all over the place.
Those sites worked with Zope 2.9 and broke down after an upgrade to 2.12. That's a not very nice thing to do to your users...
They broke down after the move to Zope 2.10. We switched Zope 2 to using the zope.tal / zope.tales packages in favor of Zope 2's own implementation. As a result TAL uses Unicode internally ever since. There's the whole unicoderesolver story, which allows you to implement an application specific fallback story. We decided back then, that dealing with this problem would be left to each application, as Zope 2 in general has too little knowledge about your data - and nobody volunteered to do any work on it ;) Plone has implemented a specific fallback story which automatically converts all utf-8 encoded strings to Unicode. In the Plone 3.x series it accepted all otherwise encoded strings and converted them via unicode(text, 'utf-8', 'ignore'), logging such occurrences. In Plone 4 it throws an exception on any non-utf-8 non unicode data. In Plone 5 we'll probably log warnings for utf-8 encoded strings and push the responsibility to convert to Unicode into the application code. If you have a rather large application with third-party plugins and have to deal with the encoded string to Unicode conversion, I think such a long term upgrade story with policy changes happening around major releases is the only way to go. If you have a pure-inhouse application you can do a data and code conversion as single project and get over with. That being said, I'd like to see someone tackle the "id" / url segments as Unicode problem. They are currently restricted to ASCII, which means we don't have a problem with arbitrary encoded string data. But there's probably enough places that rely on them being ASCII in some way. Hanno
On Thu, Apr 01, 2010 at 02:47:36PM +0200, Hanno Schlichting wrote:
On Thu, Apr 1, 2010 at 11:52 AM, Marius Gedminas <marius@gedmin.as> wrote:
I don't think I'll be able to work on it, but I think it's worth consideration: Unicode issues with Zope 2.12. I've seen these on at least three different Zope 2 sites built with a combination of TTW page templates, Python scripts and (sometimes) DTML documents: things like title attributes store their data as UTF-8 strings, while page templates insist on Unicode objects, resulting in errors all over the place.
Those sites worked with Zope 2.9 and broke down after an upgrade to 2.12. That's a not very nice thing to do to your users...
They broke down after the move to Zope 2.10.
Probably; the sites I helped upgrade skipped over 2.10 and 2.11.
We switched Zope 2 to using the zope.tal / zope.tales packages in favor of Zope 2's own implementation. As a result TAL uses Unicode internally ever since. There's the whole unicoderesolver story, which allows you to implement an application specific fallback story. We decided back then, that dealing with this problem would be left to each application, as Zope 2 in general has too little knowledge about your data - and nobody volunteered to do any work on it ;)
What if there's no application, just a Zope 2 website, using TTW scripts for implementing things like navigation menus? E.g. Page Templates come with a 'title' property of type string, not ustring, and there are big fat bold warnings not to delete it, which would be a prerequisite for creating an ustring version.
If you have a rather large application with third-party plugins and have to deal with the encoded string to Unicode conversion, I think such a long term upgrade story with policy changes happening around major releases is the only way to go. If you have a pure-inhouse application you can do a data and code conversion as single project and get over with.
How can I do a data conversion when the data in question is owned and managed by core Zope 2 objects, that can't agree on a common data format (string versus unicode)? Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote:
On Thu, Apr 1, 2010 at 3:49 AM, Martin Aspeli <optilude+lists@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.
"GOOOOOOOOOOOOOOOOOOOOOOAL! And the crowd goes wild!"
- 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.
Yay!
- 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 :)
My branch is here: svn+ssh://svn.zope.org/repos/main/Zope/branches/tseaver-fix_wsgi We'll see how it goes: I would be comfortable backporting to 2.12.x myself, unless something wildly unexpected turns up.
- 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.
You're too optimistic: I'm betting ZTK won't have made anything more than a 1.0 release by then.
- 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.
As you saw yesterday, we need to leave some more BBB lying around for the moved functionality.
- 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.
Getting the Hurt^WHelpSystem out of the way would make ZCTextIndex a non-dependency of anything else: what if we made it a standalone product? Disentanglingh DocumentTemplate and AccessControl is a wicked hard problem. I have a sense that we may need to create one or more new modules as layers to fix the cycles in that graph.
- 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.
Ideally, all of the 'Products' should be released (and some thereby abandoned :) separately.
- 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.
Yup.
- Python 3.x
Not on the agenda. We'll need to tackle this on the ZTK level first.
I don't see any chance of getting ZTK compatible before the end of the year.
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.
I would say that we need to push the Plone folks to change their policy here: their unwillingness to update from 2.10 to 2.11 was a major drag on our process (we *still* to keep 2.10 alive). In effect, all Plone3 users are *more* at risk because of that policy than if they had upgraded, because they aren't getting high-quality support for the Zope and Python versions they chose to freeze themselves to. I would rather see smaller, easier, and more frequent 2.x releases from Zope, with improved factoring and testability reducing the risks of the update for Plone.
All that said, we'll change plans if something comes up and a better plan suggests itself. The above list is obviously non-exclusive, so if someone else has anything he wants to work on, announce it, discuss it and we'll decide when and how it gets in.
Sounds good. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAku04SYACgkQ+gerLs4ltQ6mQQCfbt1pPe7WnanRypKY4hpH2uAG KCgAni1TTW5T5Zu0AzSP7YErnPLG/Yjo =FakO -----END PGP SIGNATURE-----
participants (5)
-
Charlie Clark -
Hanno Schlichting -
Marius Gedminas -
Martin Aspeli -
Tres Seaver