[Zope-dev] Zope 2.13 roadmap

[Hanno Schlichting]

On Thu, Apr 1, 2010 at 9:33 AM, Martin Aspeli <optilude+lists at 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