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:
