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