[Zope-dev] direction

[Tobias Helfrich]

Hi, this is my first posting on the list, so please be kind 
if i make some mistakes ;-) 

> On Sun, Jul 3, 2011 at 1:03 AM, Leonardo Rochael Almeida 
> <leorochael at gmail.com> wrote:
> > I noticed you've been very busy doing clean-up on the Zope2 
> code base 
> > in the last few hours. As someone who has recently spent a 
> lot of time 
> > porting forward a large and mission-critical code base, ERP5, from 
> > Zope 2.8 to Zope 2.12, I'm a little confused about the 
> direction that 
> > you're moving, and how much effort that could mean for 
> future porting 
> > efforts for Nexedi.
> 
> 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.
> 
> 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.

I agree with you. Evolution is better then revolution.

> 
> If you are interested in stability I think sticking with an "older"
> version of Zope 2 is a completely sane and good approach. 

OK, so you do think that we might use Zope 2.12 for a quite long time 
without thinking about anymore updates? Will there be any security
updates 
for Zope 2.12 in the future?

> 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.

Unfortunately i am not really able to help or work on the codebase, 
but we are using Zope 2.x for several years now.

> 
> > 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

OK, we're not using any of the stated functionality, but what is 
the reason for removing "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

We are using the virtual host monster (at least one per instance), 
we are using the error_log as well in all our applications. Are there 
any alternatives already?

> - 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

Hmm, i am not that much into Zopes structure, but if we are using 
request.SESSION we are in the need of the browser id manager, the 
session data manager and the temporary storage as well, right? 

> - 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)

Does this mean, if i want to use a DTML method in a folder structure
like 
this: /a/b/c/d/e i will have to know which level the method exists? We
are 
using a lot of methods stored in folder "a" but used from folder "b" to
"e"...
Or can you give me a short explanation about what Acquisition.Implicit
does?

> - 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)
> - Once most of the ZMI is gone, it should be feasible to drop 
> DTML or rewrite what little is left as page templates

Now i am completely shocked. We are building web applications for 
the last 6 years in Zope 2.x. All those applications are using the
following
techniques:
- DTML method/document
- Z MySQL Database Connection and Z SQL Method
- MailHost / MailDrop Host
- RAM Cache Manager
- acl_users User Folder
- Script (Python)
- External Method
- error_log
- File, Image, ExtFile and ExtImage
- REQUEST / REQUEST.SESSION
- Virtual Host Monster
- Browser Id Manager
- Session Data Manager / Session Data Container
- Temporary Folder 

This would mean to migrate at least one hundred projects from DTML to
TAL/ZPT?
Please, what is this all about? If i read the following: 
http://www.zope.org/Members/regebro/zpt_vs_dtml/ i thought it would be
fine to 
to all the development with DTML if suitable. We had no cause to switch
to TAL/ZPT 
in the last years, so that would be a disaster to do that now for so
many projects.

Can you explain me the reasons for removing DTML?

> 
> 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.
> 
> Hanno

Thanks for your informationen, even if it makes me feel uncomfortable...

Toby