[Zope-dev] direction

[Leonardo Rochael Almeida]

Hi Hanno,

>From the point of view of the ERP5 codebase, this direction for Zope2
should be mostly ok, save for a few comments below:

On Sun, Jul 3, 2011 at 03:41, Hanno Schlichting <hanno at hannosch.eu> wrote:
> On Sun, Jul 3, 2011 at 1:03 AM, Leonardo Rochael Almeida
> <leorochael at gmail.com> wrote:
>> [...]
>
> I think moving to Zope 2.12 and 2.13 does have some value for Nexedi
> or other large existing codebases, as you get support for current
> versions of the ZODB, Zope Toolkit packages and support for Python 2.7
> with Zope 2.13. Since Python 2.7 is a long-term maintenance release
> for Python itself, this should provide a stable and good basis for the
> next years - the statements from the Python community aren't
> completely clear - but I'd expect to see ongoing maintenance until
> 2013 or maybe even 2015.

Yes, these were the reasons we ported to Zope 2.12 to begin with.

> Going forward I can see two paths for Zope 2. Either we don't touch it
> at all anymore and let it bitrot or we try to move it forward and
> adept it to current best practices of development. Since complete
> rewrites almost always fail, like we have seen with Zope 3 - I prefer
> changing Zope 2.

Agreed.

> If you are interested in stability I think sticking with an "older"
> version of Zope 2 is a completely sane and good approach. What me and
> others from the Plone community are trying to do with the Zope 2
> codebase is to actually move it forward. We can either do that as part
> of the official Zope 2 release series or fork the codebase. Since so
> far there isn't really anyone else interested in working on the Zope 2
> codebase, we keep changing Zope 2 without forking it.

With the direction the Zope2 codebase has taken so far, I don't see
any reason to fork it even if all current players keep depending on
it.

>> But can you explain to us a little of how you expect Zope2 to behave
>> with the changes you're doing?
>
> There's a number of things I want to do. Not sure when I'll or others
> will have the time, but these are things I expect to happen in the
> next months or releases:
>
> - Continue to remove functionality tailored for TTW development, like
> SiteRoot, AccessRules, HelpSys and step-by-step most of the ZMI
> - Document and use the WSGI publisher and remove obsoleted
> functionality like the virtual host monster, error_log,
> ZServer/medusa, zopectl/zdaemon

In ERP5, we've made TTW development sane and safe, and integrated with
VCSs (both SVN and Git), so the above paragraph sounds  a little bit
scary, though in reality it doesn't have to be.

SiteRoot, AccessRules, HelpSys, of course, are really unused, so I
don't fear their disappearance.

As for the rest, most of the things that have been removed from core
were done in such a way that they can still be used with Zope2, so
ERP5 can happily keep using them. If things can keep evolving with
this care we should be ok.

As others have pointed out, the core url rewriting functionality of
VHM is useful even in a WSGI context, and I'd argue that it should
actually be made part of the root Application, so that we don't need a
persistent object just for this.

On the other hand, if we could get the ZTK version of this working
(the one that used /++vh-host and /++vh-root url segments) I think it
should be ok, and we could get rid of VHM completely.

> - Make the browser id manager, session data manager, temporary storage
> optional and remove it and request.SESSION from the core, instead we
> can use something based on Products.BeakerSessionDataManager /
> collective.beaker if someone has a need for sessions
> - Start using and storing parent pointers and remove
> Acquisition.Implicit from the most common base classes (a branch for
> this already exists with almost all core tests passing)

ERP5 will probably get rid of all its uses of acquisition too at some
point. We've recently taken a large step in this direction, but again,
it can still be used as an add-on, so this is not a problem.

> - Merge five.pt (Chameleon) into the core and use it instead of the
> zope.tal/zope.tales implementation (which means no more
> RestrictedPython for templates).

A few months ago, I and Malthe did some work to make sure that TTW
ZPTs worked with five.pt. Malthe even surprised me with something that
I thought couldn't possibly work and managed to get the
RestrictedPython evaluator to translate python expressions in TTW
ZPTs. So, getting rid of RestrictedPython is not strictly necessary
for using five.pt in Zope2 core.

Then again, we might decide to get rid of it for other reasons...

Anyway, as long as there are still TTW addable ZPTs, PythonScripts and
ZSQLMethods, ERP5 can still work.

> - Once most of the ZMI is gone, it should be feasible to drop DTML or
> rewrite what little is left as page templates

If DTML is still available as an optional product/package, this should
not be a problem for us, but we'll likely depend on ZSQLMethods
(hence, on DTML) for a long time, since our ZSQLCatalog functionality
is built heavily around it.

> I think what's going to stay is AccessControl, OFS (a bit lighter),
> ZPublisher (WSGI), the ZODB, ZCatalog and all the wiring for a set of
> Zope Toolkit libraries like components, events, browser pages and so
> on.
>
> That's the kind of scope that should be possible to port to Python 3
> and actually modernize enough to be understandable. At that point we
> should even be able to catch up with years of missed security updates
> - almost nothing in current Zope 2 protects against XSS, CSRF or any
> of the other common security risks we have on the web today.
>
> What I'm outlining here has of course almost nothing to do with the
> original idea and scope of Zope 2. Maybe at some point this should get
> a different name ;-)
>
> I hope this makes the direction of where I am headed clearer or more
> generally what Plone expects from its underlying framework.

Thanks Hanno,

This is a good overview, and I'm hopeful we can keep collaborating on
and evolving the same Zope2 codebase without divergence.

There are a few more specific details I'd like to talk about, though.

For example the Control_Panel on trunk is losing most of its
functionality, and becoming a purely virtual entry in the application
root. That (and the removal of product installation) means, for
example, that products that used to add icons into the Control_Panel
will no longer work.

(yes, we have one of those, for dynamically multiplexing clock_server
calls into persistent objects without needing to change configuration
and restart Zope).

This one is rather easy to fix, we just need to move the object from
the Control_Panel into the Application Root, so I mention this for
future reference, in case others have this problem.

But, for example, you committed some changes (and todos) relating to
removing icons. Out of curiosity What is the reasoning behind this?

These kinds of changes, and the steps that should be taken to deal
with them while migrating, are the kind of thing I'd like to see
discussed here while the changes are ongoing, so that we don't have
much headache while porting in the future.

Cheers,

Leo