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
On Tue, Jul 5, 2011 at 10:19 AM, Tobias Helfrich <Helfrich@know-it.net> wrote:
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?
You want to use Zope 2.13. 2.12 is at the end of its active maintenance cycle as is Python 2.6 (the only Python version it supports). Zope 2.13 brings support for Python 2.7, which is a long-term maintenance release. How long Zope 2.13 is going to be supported and sees security fixes will depend on the community. The Plone community will use it for its 4.1 and 4.2 releases, as a result of our security policy that should result in us supporting Zope 2.13 for the next two years. Beyond that nobody knows what will happen.
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:
[snip] What you are describing is exactly what I meant by old legacy Zope2 applications. You should be able to use this style of development with Zope 2.13. But you won't be able to upgrade to newer versions of Zope 2 anymore and expect your code to work unmodified. We discouraged this style of development for the past six years. It should come as no surprise that it will come to an end at some point. Hanno
On 5 July 2011 09:42, Hanno Schlichting <hanno@hannosch.eu> wrote:
What you are describing is exactly what I meant by old legacy Zope2 applications.
You should be able to use this style of development with Zope 2.13. But you won't be able to upgrade to newer versions of Zope 2 anymore and expect your code to work unmodified. We discouraged this style of development for the past six years. It should come as no surprise that it will come to an end at some point.
I would've thought it would also be possible for those who rely on this to maintain the relevant eggs as optional installations against Zope 2.x, no? Martin
On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli <optilude+lists@gmail.com> wrote:
I would've thought it would also be possible for those who rely on this to maintain the relevant eggs as optional installations against Zope 2.x, no?
The ZMI is not a package - we don't have a split into zope and zope.app in Zope2. Once there's no more ZMI, Products.PageTemplates stops using RestrictedPython and the OFS base classes don't inherit from Acquisition.Implicit anymore, it'll be really hard to keep the legacy development approach working. Someone might try, but I think it's not a wise decision to spent any resources that way. At some point every application written in the legacy style has to be rewritten. I think it would be a better use of resources for anyone to start doing that than maintaining a dead-end. Hanno
On 5 July 2011 10:18, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli <optilude+lists@gmail.com> wrote:
I would've thought it would also be possible for those who rely on this to maintain the relevant eggs as optional installations against Zope 2.x, no?
The ZMI is not a package - we don't have a split into zope and zope.app in Zope2. Once there's no more ZMI, Products.PageTemplates stops using RestrictedPython and the OFS base classes don't inherit from Acquisition.Implicit anymore, it'll be really hard to keep the legacy development approach working.
I think it might be useful to spell out the reasons behind this (here, or better yet, somewhere more permanent like zope.org). I can imagine people reading this and wondering why it's a good idea, especially those who have an investment in the existing technologies.
Someone might try, but I think it's not a wise decision to spent any resources that way. At some point every application written in the legacy style has to be rewritten. I think it would be a better use of resources for anyone to start doing that than maintaining a dead-end.
This is a pretty sweeping statement that I think could cause a lot of nervousness. It might be the right thing in many ways, but we need to at least provide a bit more context. If you're a business that's invested dozens of person-years into a product, the prospect of rewriting could seem fairly daunting. At least we, as the Zope 2 community, need to set out the case for change and some kind of idea of timing and transition path, even if that means in some cases getting to a "long term maintenance" release and in other cases evolving away from certain technologies whilst being confident to keep using others. Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 05.07.2011 11:30, schrieb Martin Aspeli:
On 5 July 2011 10:18, Hanno Schlichting <hanno@hannosch.eu <mailto:hanno@hannosch.eu>> wrote:
On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli <optilude+lists@gmail.com <mailto:optilude%2Blists@gmail.com>> wrote: > I would've thought it would also be possible for those who rely on this to > maintain the relevant eggs as optional installations against Zope 2.x, no?
The ZMI is not a package - we don't have a split into zope and zope.app in Zope2. Once there's no more ZMI, Products.PageTemplates stops using RestrictedPython and the OFS base classes don't inherit from Acquisition.Implicit anymore, it'll be really hard to keep the legacy development approach working.
I think it might be useful to spell out the reasons behind this (here, or better yet, somewhere more permanent like zope.org <http://zope.org>). I can imagine people reading this and wondering why it's a good idea, especially those who have an investment in the existing technologies.
Someone might try, but I think it's not a wise decision to spent any resources that way. At some point every application written in the legacy style has to be rewritten. I think it would be a better use of resources for anyone to start doing that than maintaining a dead-end.
This is a pretty sweeping statement that I think could cause a lot of nervousness. It might be the right thing in many ways, but we need to at least provide a bit more context. If you're a business that's invested dozens of person-years into a product, the prospect of rewriting could seem fairly daunting. At least we, as the Zope 2 community, need to set out the case for change and some kind of idea of timing and transition path, even if that means in some cases getting to a "long term maintenance" release and in other cases evolving away from certain technologies whilst being confident to keep using others.
I agree with Martin, that a sane upgrade path should be provided at least. If people still use things like DTML, the ZMI, etc., then it would be highly frustrating for them to simply drop these. You can split the components from the base and provide them as optional where possible. This seems to be possible with most of the components that Hanno listed as depreciated/to be removed soon. And most importantly: provide sane upgrade paths for depreciated components. If the ancient session management from Zope2 is to be dropped, tell people what they should use instead, and how to migrate their old_but_still_in_use applications/projects. Greetings, jonas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOEudWAAoJEFJi5/9JEEn+jXcP/RyNZw1JFfPqG/nzacqAbx4F WdoZGyARkGVV1BTEtE6/cvkJCnHNuBgEaeAtGJY7h5HdqT781uKNdhJurncA8ii3 7RXm0CVJ1AZXdycDT0DoOMyYWBx345cglk5S+5bbfIdMWVvPNyDgQhIjFRT20jA7 cMi8e4mStgd2upwS487L+FubmkWyOw8d8bUbL+SFvykNOEXr6OqwTHLTBWh4yVi3 //zmV6T/wtmcpIyiqdx4VkdvmmttJbM2ro0FcIvO46XHD87XrYSiyEZM3XiYsjiF 8hNqhHtkiA/mLRXw6jIDhMvzvIsgKsWdHMmR2OOGVPY5nnWuvmBimaSj+u01TJIS K1MLMNnheTqH7alr7Mn0PmIGfbX4ED9DwzrR2yen6iHmWqgHShDC+OAFrRzFBK51 fPnLlAVQrQSDLPhhm+Ytv55o/hzmzARUUnta4d+Ac2k0y/DLXuz+8svSdfLuKVyv 0W5onVnLuXH5z5X3HM5ubywUdyfOaVgCIYdV+vVh9tQCeLZsDN6rVl+4H5WCQuNk J17+m4B59zAxAhIxa0ZwnLHVwO+GgP+pIHhQtSZGF1WY43wBFPDxKtt8xxBCjPvk LyMPgevwTn4rhETwkCsZFqMvVGBa/AmKX3suQhNBNFr+8qOy/H/q4tOQGpUyBmNE nVJtAfGh/G+ecROUKMAW =eItl -----END PGP SIGNATURE-----
Hi Hanno, On Tue, Jul 5, 2011 at 11:18, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli <optilude+lists@gmail.com> wrote:
I would've thought it would also be possible for those who rely on this to maintain the relevant eggs as optional installations against Zope 2.x, no?
The ZMI is not a package - we don't have a split into zope and zope.app in Zope2. Once there's no more ZMI, Products.PageTemplates stops using RestrictedPython and the OFS base classes don't inherit from Acquisition.Implicit anymore, it'll be really hard to keep the legacy development approach working.
I guess this is the biggest point of contention. Why does the ZMI have to go? Although both Plone and ERP5 strive to gradually replace ZMI based configuration with "native" interfaces (native to Plone/ERP5), isn't there value in having a minimal OFS browser with the ability to Add/Delete/Copy/Cut/Paste objects as a fallback? It doesn't seem to conflict with your stated goal: "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.(...)" Or to put it differently, in which way does having a minimalistic OFS browser for a ZMI conflicts or hinders Plone's objectives for the Zope2 code base? If we still have that minimalistic ZMI, all players in our community can decide how much effort they want to spend maintaining which legacy pieces technology, depending on what makes economic sense to them, without causing extra maintenance burden on the other players.
[...]
Cheers, Leo
On 5 July 2011 20:21, Leonardo Rochael Almeida <leorochael@gmail.com> wrote:
Hi Hanno,
On Tue, Jul 5, 2011 at 11:18, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli <optilude+lists@gmail.com> wrote:
I would've thought it would also be possible for those who rely on this to maintain the relevant eggs as optional installations against Zope 2.x, no?
The ZMI is not a package - we don't have a split into zope and zope.app in Zope2. Once there's no more ZMI, Products.PageTemplates stops using RestrictedPython and the OFS base classes don't inherit from Acquisition.Implicit anymore, it'll be really hard to keep the legacy development approach working.
I guess this is the biggest point of contention. Why does the ZMI have to go? Although both Plone and ERP5 strive to gradually replace ZMI based configuration with "native" interfaces (native to Plone/ERP5), isn't there value in having a minimal OFS browser with the ability to Add/Delete/Copy/Cut/Paste objects as a fallback? It doesn't seem to conflict with your stated goal:
"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.(...)"
Or to put it differently, in which way does having a minimalistic OFS browser for a ZMI conflicts or hinders Plone's objectives for the Zope2 code base?
If we still have that minimalistic ZMI, all players in our community can decide how much effort they want to spend maintaining which legacy pieces technology, depending on what makes economic sense to them, without causing extra maintenance burden on the other players.
I think the problem with the current ZMI is that it brings in a whole load of dependencies that we don't otherwise need - if it were minimalistic it wouldn't be a problem. I'm all for someone writing a very simple object browser though, it would make a great optional package. I'm certainly interested in moving away from OFS in the medium term towards the much simpler ZTK / Pyramid approach of __getitem__ traversal. Laurence
I'm sorry, I don't really understand the current line of discussion yet. I see a lot of discussion which part is going to be cut out and dropped, or replaced. I haven't yet understood what's the end target for the project. So, are you guys expecting to get Zope into a shape where it will attract new users and be a viable player again? Or, isn't the line currently that "nobody uses Zope for new projects anyway"? In case that we believe that no new users are attracted to Zope, wouldn't that mean that resources should go to make Zope into a shape that helps existing applications run on Zope and survive? Modernize the code, but break as little as possible in the process. As someone said, what's the use for a company that has invested a lot of money in a Zope Product, if there is something called "Zope" around, but they can't use it without a major rewrite? In case all these changes are made to make Zope again into a shiny new framework that will attract new users, what's the use? Wouldn't people go to pyramid anyway? There they have all that stuff already - but right *now*. Looking at the descriptions here, in that line of thought and in the long run we'll end up with something like pyramid in a few years, only with a lot more disgruntled former users and much more confusion about the name. When you change the name in the end, you've come full circle anyway. Regards, Sascha
On 6 July 2011 15:27, Sascha Welter <zopelist@betabug.ch> wrote:
I'm sorry, I don't really understand the current line of discussion yet.
I see a lot of discussion which part is going to be cut out and dropped, or replaced. I haven't yet understood what's the end target for the project.
So, are you guys expecting to get Zope into a shape where it will attract new users and be a viable player again? Or, isn't the line currently that "nobody uses Zope for new projects anyway"?
In case that we believe that no new users are attracted to Zope, wouldn't that mean that resources should go to make Zope into a shape that helps existing applications run on Zope and survive? Modernize the code, but break as little as possible in the process. As someone said, what's the use for a company that has invested a lot of money in a Zope Product, if there is something called "Zope" around, but they can't use it without a major rewrite?
In case all these changes are made to make Zope again into a shiny new framework that will attract new users, what's the use? Wouldn't people go to pyramid anyway? There they have all that stuff already - but right *now*.
Looking at the descriptions here, in that line of thought and in the long run we'll end up with something like pyramid in a few years, only with a lot more disgruntled former users and much more confusion about the name. When you change the name in the end, you've come full circle anyway.
Zope in it's current form is not maintainable in the long run. There are too many alternative ways of achieving the same thing. Over the next few years we will need to start moving to Python 3, and the only way to make that port possible is by reducing the size of the codebase. As a Plone developer, my interest is in how we make Zope into something that enables Plone to continue evolving and developing, to port to Python 3 and increasingly use more standard WSGI components. Rewriting in Pyramid is not an option for us, large rewrites generally fail (even if they do produce excellent new technology along the way...) Of course if people who have legacy applications want to continue maintaining a 'Classic' Zope 2 in it's current form then they are free to do so, but it won't happen without investment on their part. I expect they will have similar concerns to the Plone developers, and may find the same reduction and evolution approach to Zope useful. Laurence
Hi. On Tue, Jul 5, 2011 at 9:21 PM, Leonardo Rochael Almeida <leorochael@gmail.com> wrote:
I guess this is the biggest point of contention. Why does the ZMI have to go? Although both Plone and ERP5 strive to gradually replace ZMI based configuration with "native" interfaces (native to Plone/ERP5), isn't there value in having a minimal OFS browser with the ability to Add/Delete/Copy/Cut/Paste objects as a fallback? It doesn't seem to conflict with your stated goal:
I think having a minimal database browser is a good idea. I think something like https://github.com/davisagli/eye is the right starting point here. I don't want to have anything that lives in the same process as the rest of the application code. The ZMI is currently like running phpMyAdmin accessible to the world with the same credentials and on the same domain as the rest of your application. It's a huge security risk and pollutes model classes and views in the application code.
Or to put it differently, in which way does having a minimalistic OFS browser for a ZMI conflicts or hinders Plone's objectives for the Zope2 code base?
The ZMI is a highly insecure, completely outdated and user-unfriendly interface. On the security level, there's no validation of user-input, there's no XSS and CSRF protection. Anyone being logged into your application who has ZMI access is susceptible to a large number of attacks. There's too much of stone-age code based on no-patterns to prevent these attacks - we can currently only fix them in a tedious process of finding one exploit after the other. We need a better strategy here - and the only one I can see is removing the existing ZMI code and moving any low-level interface to a completely separate codebase and process. On the other points, at least Plone tries to use modern web technologies and for example we just switched to a HTML5 doctype - having any end-user go to the ZMI and look at a frames-based interface undermines any marketing message we try to put out about being modern. And then the ZMI doesn't even do basic things like asking you for confirmation before removing your entire site and being in almost all regards a huge usability fail - again completely add odds with Plone's good end-user usability story. On the code level the ZMI-support code is mixed into all other model code and has often lead to arcane developer API's. There's far too many places where a manage_* method with a request argument is the only way to achieve anything. For whatever code we'll end up with in two to three years, I want to see good developer API's that actually make you productive. I hope this clarifies a bit more, why I feel the ZMI is an arcane beast that needs to be hunted down sooner than later. Hanno
On 07/06/2011 10:59 AM, Hanno Schlichting wrote:
The ZMI is a highly insecure, completely outdated and user-unfriendly interface.
As I read this, I got an idea for a possible way forward. I haven't been reading zope-dev much lately, so forgive me if something like this has been mentioned already. What if we had decorators that let us disable old code by default, yet allowed users to enable the old code with configuration? Something like this: import zope.oldcode class SomeClass(SimpleObject): @zope.oldcode.zmi def manage_edit(self, REQUEST): # ... The idea here is we'll create a zope.oldcode egg and fill it with decorators for pervasive features of Zope that need to be removed over time, such as the current ZMI. We'll also create a configuration switch for each of those old features so that people can keep using them for a reasonable period of time. When the "zmi" feature is disabled, the code above will replace the manage_edit method with a "zope.oldcode.Disabled" object that raises a helpful exception if anyone tries to call it. It would also be good to make these decorators implement __nonzero__ to allow conditional attribute definition: if zope.oldcode.zmi: manage_properties = (...) I would want to make sure conditional tests are possible as well: @zope.oldcode.zmi def test_manage_edit(self): # ... (The zope.oldcode package probably ought to enable all old features by default when running tests.) What do you think? Shane
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/07/2011 03:24 AM, Shane Hathaway wrote:
On 07/06/2011 10:59 AM, Hanno Schlichting wrote:
The ZMI is a highly insecure, completely outdated and user-unfriendly interface.
As I read this, I got an idea for a possible way forward. I haven't been reading zope-dev much lately, so forgive me if something like this has been mentioned already.
What if we had decorators that let us disable old code by default, yet allowed users to enable the old code with configuration? Something like this:
import zope.oldcode
class SomeClass(SimpleObject):
@zope.oldcode.zmi def manage_edit(self, REQUEST): # ...
The idea here is we'll create a zope.oldcode egg and fill it with decorators for pervasive features of Zope that need to be removed over time, such as the current ZMI. We'll also create a configuration switch for each of those old features so that people can keep using them for a reasonable period of time. When the "zmi" feature is disabled, the code above will replace the manage_edit method with a "zope.oldcode.Disabled" object that raises a helpful exception if anyone tries to call it.
It would also be good to make these decorators implement __nonzero__ to allow conditional attribute definition:
if zope.oldcode.zmi: manage_properties = (...)
I would want to make sure conditional tests are possible as well:
@zope.oldcode.zmi def test_manage_edit(self): # ...
(The zope.oldcode package probably ought to enable all old features by default when running tests.)
What do you think?
Neat -- sounds like an interesting thing to try a "spike" on, anyway. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4WLuwACgkQ+gerLs4ltQ46IgCgivBo8ucn91ix8YlsYknNG7HB +fcAn2wyEQoKNNpZ+yv5OXHi9vKmtiHh =Dm5a -----END PGP SIGNATURE-----
Hi Hanno
On Tue, Jul 5, 2011 at 10:19 AM, Tobias Helfrich <Helfrich@know-it.net> wrote:
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?
You want to use Zope 2.13. 2.12 is at the end of its active maintenance cycle as is Python 2.6 (the only Python version it supports).
Zope 2.13 brings support for Python 2.7, which is a long-term maintenance release.
OK, thx for the info. So we will be able to use Zope 2.13 with the techniques mentioned before? That will give us another two years to think about going on with different styles. So basically Zope 2 will be the framework for Plone only, because the community which is/was using Zope 2 for standalone individual projects has decreased to nearly none. So it might be a good idea to look for something completely different? I don't think that Plone will be able to do everything we want it to. Or do you think we can stick with Zope 2 but change the way of building applications to ZPT/TAL? So we have to get rid of all DTML and what about an alternative to the ZSQL Methods?
How long Zope 2.13 is going to be supported and sees security fixes will depend on the community. The Plone community will use it for its 4.1 and 4.2 releases, as a result of our security policy that should result in us supporting Zope 2.13 for the next two years. Beyond that nobody knows what will happen.
I do agree.
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:
[snip]
What you are describing is exactly what I meant by old legacy Zope2 applications.
You should be able to use this style of development with Zope 2.13. But you won't be able to upgrade to newer versions of Zope 2 anymore and expect your code to work unmodified. We discouraged this style of development for the past six years. It should come as no surprise that it will come to an end at some point.
OK, i have subscribed to the mailing list today, so unfortunately i haven't found this sort of information anywhere else. I don't want to blame you or anyone else for that, but it's not nice to hear that right now :-( It might has been too confusing in the past, with Zope 3 being such a mistake and of course i haven't really checked whether to change something or not...
Hanno
Toby
Hi, On 5 July 2011 11:26, Tobias Helfrich <Helfrich@know-it.net> wrote:
Hi Hanno
On Tue, Jul 5, 2011 at 10:19 AM, Tobias Helfrich <Helfrich@know-it.net> wrote:
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?
You want to use Zope 2.13. 2.12 is at the end of its active maintenance cycle as is Python 2.6 (the only Python version it supports).
Zope 2.13 brings support for Python 2.7, which is a long-term maintenance release.
OK, thx for the info. So we will be able to use Zope 2.13 with the techniques mentioned before? That will give us another two years to think about going on with different styles. So basically Zope 2 will be the framework for Plone only, because the community which is/was using Zope 2 for standalone individual projects has decreased to nearly none.
I think it would be very sad if that happened, especially since there evidently demand from other projects. What I think is clear is that to evolve Zope 2, we need to shed some baggage and make some deeper changes to allow us to achieve some of our goals (e.g. WSGI, simplified stack, simpler and more easily controllable security, less magical traversal, more comprehensible publisher). Plone is obviously a big consumer of Zope 2 and I would expect Plone to have a major influence on Zope 2's evolution. But ERP5 is another big consumer, and we shouldn't ignore that.
So it might be a good idea to look for something completely different? I don't think that Plone will be able to do everything we want it to. Or do you think we can stick with Zope 2 but change the way of building applications to ZPT/TAL? So we have to get rid of all DTML and what about an alternative to the ZSQL Methods?
I think keeping DTML as an optional installation should be quite feasible. It's just possibly not something that the core Zope 2 team want to maintain anymore in the standard distribution. ZSQL Methods may be a similar story, in fact, especially as they rely on DTML. However, I'd encourage you to look at SQLAlchemy, which is way nicer to work with.
OK, i have subscribed to the mailing list today, so unfortunately i haven't found this sort of information anywhere else. I don't want to blame you or anyone else for that, but it's not nice to hear that right now :-(
I think there is some characteristic bluntness in Hanno's emails, but please realise that none of this is going to happen over night, and existing codebases are not going to magically disappear. Sometimes we have to be a bit more radical to understand the art of the possible and build a future platform that will support future needs. That doesn't mean there can't be both migration paths and long-term stable versions. Martin
On Tue, 5 Jul 2011 12:11:40 +0100 Martin Aspeli <optilude+lists@gmail.com> wrote:
Hi,
Hello,
I think it would be very sad if that happened, especially since there evidently demand from other projects.
What I think is clear is that to evolve Zope 2, we need to shed some baggage and make some deeper changes to allow us to achieve some of our goals (e.g. WSGI, simplified stack, simpler and more easily controllable security, less magical traversal, more comprehensible publisher).
Plone is obviously a big consumer of Zope 2 and I would expect Plone to have a major influence on Zope 2's evolution. But ERP5 is another big consumer, and we shouldn't ignore that.
And Silva. And maybe other companies that have a product and are not big enough to develop their product AND the framework they use. Regards, Sylvain -- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands
participants (10)
-
Hanno Schlichting -
Jonas Meurer -
Laurence Rowe -
Leonardo Rochael Almeida -
Martin Aspeli -
Sascha Welter -
Shane Hathaway -
Sylvain Viollon -
Tobias Helfrich -
Tres Seaver