Hi Hanno, First of all, thank you very much for all you hard work, specially with the security issues. 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. Now I don't want to provide any stop energy, and I understand that discussing ideas on Zope-dev can sometimes lead to them being dragged into bike-shed designing contests, rather than being implemented, so I fully appreciate you wanting to do more than to talk. And specially appreciated the effort you spent in the past spinning many components out of the Zope2 code base and into optional components, making it all a lot more maintainable. But can you explain to us a little of how you expect Zope2 to behave with the changes you're doing? It would be nice to have a record on the mailing list that we can point to so that people who have difficulties porting their software in the future can understand how to proceed. Thanks in advance, Leo
On Sun, Jul 3, 2011 at 1:03 AM, Leonardo Rochael Almeida <leorochael@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. 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.
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 - 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) - 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 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
On Sun, 2011-07-03 at 03:41 +0200, Hanno Schlichting wrote:
- 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
Zope still needs to the virtual host monster (or something like it) even with the WSGI publisher; there's nothing equivalent in the WSGI world (unless you could repoze.vhm, which is essentially just the virtual host monster, and probably doesn't need to live in middleware; no one uses it except people who use repoze.zope2).
- 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
I don't have any skin in this game, but FTR, Mike Bayer isn't feeling all that confident about Beaker's sessioning component (or so he has told me). Beaker was originally made as a caching component, and had sessioning jammed into it quite late; nobody is really maintaining the sessioning component of it now. - C
On Sun, Jul 3, 2011 at 7:09 AM, Chris McDonough <chrism@plope.com> wrote:
Zope still needs to the virtual host monster (or something like it) even with the WSGI publisher; there's nothing equivalent in the WSGI world (unless you could repoze.vhm, which is essentially just the virtual host monster, and probably doesn't need to live in middleware; no one uses it except people who use repoze.zope2).
I'm expecting us to use repoze.vhm. But I've left the VHM in the code, so it's easy to install one if you still need it. For some time I expect Plone to install a VHM as part of its installation process.
I don't have any skin in this game, but FTR, Mike Bayer isn't feeling all that confident about Beaker's sessioning component (or so he has told me). Beaker was originally made as a caching component, and had sessioning jammed into it quite late; nobody is really maintaining the sessioning component of it now.
Well, if I can choose between modern unmaintained code from Mike Bayer and stone-age unmaintained code from Zope, it's still an easy choice ;-) And looking at the basics of what Beaker does here, it's still much more useful and of better quality than what we have in Zope 2. If there's any other non-framework-specific session machinery out there, we could use that as well. But I think most other stuff is tied into Django. Hanno
On 3 July 2011 16:44, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Sun, Jul 3, 2011 at 7:09 AM, Chris McDonough <chrism@plope.com> wrote:
Zope still needs to the virtual host monster (or something like it) even with the WSGI publisher; there's nothing equivalent in the WSGI world (unless you could repoze.vhm, which is essentially just the virtual host monster, and probably doesn't need to live in middleware; no one uses it except people who use repoze.zope2).
I'm expecting us to use repoze.vhm. But I've left the VHM in the code, so it's easy to install one if you still need it. For some time I expect Plone to install a VHM as part of its installation process.
I don't have any skin in this game, but FTR, Mike Bayer isn't feeling all that confident about Beaker's sessioning component (or so he has told me). Beaker was originally made as a caching component, and had sessioning jammed into it quite late; nobody is really maintaining the sessioning component of it now.
Well, if I can choose between modern unmaintained code from Mike Bayer and stone-age unmaintained code from Zope, it's still an easy choice ;-)
And looking at the basics of what Beaker does here, it's still much more useful and of better quality than what we have in Zope 2.
If there's any other non-framework-specific session machinery out there, we could use that as well. But I think most other stuff is tied into Django.
FWIW, we have a high-performance, high-load application in production on Plone 4 with collective.beaker relying heavily on sessions, and I'm not aware of any problems with it. We use the memcached backend across two physical servers and a large number of Zope clients. Martin
On 2011-7-3 17:48, Martin Aspeli wrote:
FWIW, we have a high-performance, high-load application in production on Plone 4 with collective.beaker relying heavily on sessions, and I'm not aware of any problems with it. We use the memcached backend across two physical servers and a large number of Zope clients.
In my experience it depends highly on the memcache client library you use with beaker. With some the results are disastrous, with other it is stable. Where possible I have switched to cookie-based sessions to prevent stability problems. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On Sun, Jul 03, 2011 at 06:10:48PM +0200, Wichert Akkerman wrote:
On 2011-7-3 17:48, Martin Aspeli wrote:
FWIW, we have a high-performance, high-load application in production on Plone 4 with collective.beaker relying heavily on sessions, and I'm not aware of any problems with it. We use the memcached backend across two physical servers and a large number of Zope clients.
In my experience it depends highly on the memcache client library you use with beaker. With some the results are disastrous, with other it is stable. Where possible I have switched to cookie-based sessions to prevent stability problems.
Aren't all sessions cookie-based? Did you mean you switched to secure cookies instead of server-side state? Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development
On 2011-7-4 11:59, Marius Gedminas wrote:
On Sun, Jul 03, 2011 at 06:10:48PM +0200, Wichert Akkerman wrote:
On 2011-7-3 17:48, Martin Aspeli wrote:
FWIW, we have a high-performance, high-load application in production on Plone 4 with collective.beaker relying heavily on sessions, and I'm not aware of any problems with it. We use the memcached backend across two physical servers and a large number of Zope clients.
In my experience it depends highly on the memcache client library you use with beaker. With some the results are disastrous, with other it is stable. Where possible I have switched to cookie-based sessions to prevent stability problems.
Aren't all sessions cookie-based?
Did you mean you switched to secure cookies instead of server-side state?
I meant the cookie-backend, which indeed securely stores all data in a cookie instead of keeping any state serverside. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On Sun, 2011-07-03 at 17:44 +0200, Hanno Schlichting wrote:
I don't have any skin in this game, but FTR, Mike Bayer isn't feeling all that confident about Beaker's sessioning component (or so he has told me). Beaker was originally made as a caching component, and had sessioning jammed into it quite late; nobody is really maintaining the sessioning component of it now.
Well, if I can choose between modern unmaintained code from Mike Bayer and stone-age unmaintained code from Zope, it's still an easy choice ;-)
You might want to talk to Wiggy about that. He has a lot of experience with Beaker.
And looking at the basics of what Beaker does here, it's still much more useful and of better quality than what we have in Zope 2.
If there's any other non-framework-specific session machinery out there, we could use that as well. But I think most other stuff is tied into Django.
Our attempt at penance (still framework specific) is here: http://agendaless.com/Members/tseaver/software/faster/faster-0.5.1/README.tx... I don't know of any other sessioning libraries. - C
On Sun, 03 Jul 2011 01:09:17 -0400 Chris McDonough <chrism@plope.com> wrote:
On Sun, 2011-07-03 at 03:41 +0200, Hanno Schlichting wrote:
Hello,
- 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
Zope still needs to the virtual host monster (or something like it) even with the WSGI publisher; there's nothing equivalent in the WSGI world (unless you could repoze.vhm, which is essentially just the virtual host monster, and probably doesn't need to live in middleware; no one uses it except people who use repoze.zope2).
I have my own WSGI implementation, since a while, that works perfectly (infrae.wsgi), and I still do use the VirtualHostMonster (you can trash all the other things). I agree that its code might not been the best in the world, but it works for the moment and does what it says (I would love to see shiftNameToApplication implemented with more than one pass). I will sad to learn that this goes away, if nothing replace it. I kind of don't like the WSGI approach of cutting the database, traversing, authorization, rewriting Zope 2 concepts into middleware as I think they don't really fit the design of pipes provided by the WSGI middleware concept (but I do use middlewares for other things with Zope 2).
- 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
I don't have any skin in this game, but FTR, Mike Bayer isn't feeling all that confident about Beaker's sessioning component (or so he has told me). Beaker was originally made as a caching component, and had sessioning jammed into it quite late; nobody is really maintaining the sessioning component of it now.
I don't use the request.SESSION since a long time (as they are slow and badly designed in Zope 2 I think), and use beaker as a storage for the session (because it is highly configurable). However I don't directly use the session mechanism of beaker either, and I would agree with Mike Bayer. I find the beaker code messy and confusing, it sounds like it started simple, and lot of feature have been added to support everything, with backward compatibility up to the first version. And when you have a bug to look for, it is kind of spaghetti code. If that remind you an another project :). Regards, Sylvain, -- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands
On Mon, Jul 4, 2011 at 10:49 AM, Sylvain Viollon <sylvain@infrae.com> wrote:
... and I still do use the VirtualHostMonster (you can trash all the other things).
I agree that its code might not been the best in the world, but it works for the moment and does what it says (I would love to see shiftNameToApplication implemented with more than one pass).
Ok. I didn't mean to remove the VHM at any point. I removed it from the default content over the weekend but given its popularity, I think I can safely put it back. Hanno
Hi! Hanno Schlichting 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.
With the big changes you propose for Zope 2, some existing projects/deployments will stay stuck with Zope 2.13 (or Zope 2.X if Zope trunk is not released as Zope 2.14). Long-term maintenance for Zope 2.13 would give these projects/deployments at least a few more years.
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.
+1
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 don't want to discuss names, but I think the next release from Zope trunk should be explicitly a new *major* release. Cheers, Yuppie
On Mon, Jul 4, 2011 at 12:19 PM, yuppie <y.2011@wcm-solutions.de> wrote:
Long-term maintenance for Zope 2.13 would give these projects/deployments at least a few more years.
Yes. I'm willing to cut releases for it for quite a while. I just expect to see active maintenance from the Plone community to stop in a year or two. Judging from the ongoing maintenance we currently have for Zope 2.10 or 2.11 I don't think it's very realistic to expect much to happen once the Plone guys stop.
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 don't want to discuss names, but I think the next release from Zope trunk should be explicitly a new *major* release.
I think that's perfectly fine. Since I broke backwards compatibility with a number of changes I did, a major version increase is warranted. So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or 5.0 or anything else doesn't make it any better at all. So 3.0 is the most sensible one :) Hanno
On 5 July 2011 10:31, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Mon, Jul 4, 2011 at 12:19 PM, yuppie <y.2011@wcm-solutions.de> wrote:
Long-term maintenance for Zope 2.13 would give these projects/deployments at least a few more years.
Yes. I'm willing to cut releases for it for quite a while. I just expect to see active maintenance from the Plone community to stop in a year or two. Judging from the ongoing maintenance we currently have for Zope 2.10 or 2.11 I don't think it's very realistic to expect much to happen once the Plone guys stop.
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 don't want to discuss names, but I think the next release from Zope trunk should be explicitly a new *major* release.
I think that's perfectly fine. Since I broke backwards compatibility with a number of changes I did, a major version increase is warranted.
So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or 5.0 or anything else doesn't make it any better at all. So 3.0 is the most sensible one :)
Boy, that's going to be confusing. :) I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the defunct Zope 3, although I don't think there are any particularly good options here. Martin
On Tue, Jul 5, 2011 at 11:56 AM, Martin Aspeli <optilude+lists@gmail.com> wrote:
On 5 July 2011 10:31, Hanno Schlichting <hanno@hannosch.eu> wrote:
So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or 5.0 or anything else doesn't make it any better at all. So 3.0 is the most sensible one :)
Boy, that's going to be confusing. :) I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the defunct Zope 3, although I don't think there are any particularly good options here.
Zope2 4.0 would imply some sort of upgrade path from Zope 3 to this. That's as confusing as anything else and would lead to the question what happened to Zope2 3.0. Since we don't market Zope2 anymore, I think there's actually much less confusion from this than we'd fear. It's just an internal version number used in some buildout files, not something that has any particular meaning. Hanno
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 05.07.2011 12:04, schrieb Hanno Schlichting:
On Tue, Jul 5, 2011 at 11:56 AM, Martin Aspeli <optilude+lists@gmail.com> wrote:
On 5 July 2011 10:31, Hanno Schlichting <hanno@hannosch.eu> wrote:
So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or 5.0 or anything else doesn't make it any better at all. So 3.0 is the most sensible one :)
Boy, that's going to be confusing. :) I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the defunct Zope 3, although I don't think there are any particularly good options here.
Zope2 4.0 would imply some sort of upgrade path from Zope 3 to this. That's as confusing as anything else and would lead to the question what happened to Zope2 3.0.
Since we don't market Zope2 anymore, I think there's actually much less confusion from this than we'd fear. It's just an internal version number used in some buildout files, not something that has any particular meaning.
I don't like either of these solutions. And I don't agree with Hanno, that it's 'just an internal version number'. It will show up on zope.org, launchpad.net, and many more places. I would rather bump the version number to 2.20 to highlight the major changes, and keep the 2 as major for Zope2 versions. Greetings, jonas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOEuXYAAoJEFJi5/9JEEn+JS0QALwzhuqnNvVzngKpEiDRIPmG SIbAlbvUHIOb15kZCWCZlJjvmIuwHd2eQdbKScit7o/WBNzH38L5+BGoWPZil0k6 X04WmaXd/15OfWtGGkwsxG8Jt9gO5b6kvyu9a54qVdiNpHs9M5531XvCcPFyG9yY FLdmkRUMtpATg7o0YLt2B5lKWnojDvVvVgTXy8ad/UhO6TKrNzySRHLPiOhnh9LY 7axX/ExErzU9CFPB02joKP140ex5Om72L66FXWVNNZ9GUVaIT0puOTxLnbfkSahl TeItFjzby4xdQ89ot5OD7nlMgvuPx0Scstuf+GaQH60xoTDj8EIQEwoSotDYMUSD GHqD3eGsn1ORgB2ov/7dUW9xaEkLHfu7ikLozGXnD2xtGXTZG7tjuagmusV9Mftj kRjoCrSAAz8KM4FnAeLxdgYHIIEN3KRkJXeyqAMtcOoCgRZFEWILJWxcoU2CbYP9 4WAeQlnWby5KgUS+rSiJ7zLRu0uas4gAKb513jt1KJDOFSmzVQECrpQJ3bHvykK7 uVj+00/smgPk/DnCLlJTHuZwQVDEFmAtjOd31lreTHAFE46BHmbjSYMFXIHI01D4 4H4AiXlnb2BS55wH+JvmdM1+j8IkgaBI6LBtBCotpcZXSAv4/BXvCm2Ynwte/yXU GlwhHtBmyZ6HfdhuVrUI =Cir1 -----END PGP SIGNATURE-----
On 5 July 2011 11:22, Jonas Meurer <jonas@freesources.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 05.07.2011 12:04, schrieb Hanno Schlichting:
On Tue, Jul 5, 2011 at 11:56 AM, Martin Aspeli <optilude+lists@gmail.com> wrote:
On 5 July 2011 10:31, Hanno Schlichting <hanno@hannosch.eu> wrote:
So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or 5.0 or anything else doesn't make it any better at all. So 3.0 is the most sensible one :)
Boy, that's going to be confusing. :) I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the defunct Zope 3, although I don't think there are any particularly good options here.
Zope2 4.0 would imply some sort of upgrade path from Zope 3 to this. That's as confusing as anything else and would lead to the question what happened to Zope2 3.0.
Since we don't market Zope2 anymore, I think there's actually much less confusion from this than we'd fear. It's just an internal version number used in some buildout files, not something that has any particular meaning.
I don't like either of these solutions. And I don't agree with Hanno, that it's 'just an internal version number'. It will show up on zope.org, launchpad.net, and many more places.
I would rather bump the version number to 2.20 to highlight the major changes, and keep the 2 as major for Zope2 versions.
I agree with Jonas that any idea of giving a package named Zope2 a version number that is not 2.x is only going to lead to more confusion. For Zope2 we're used the x in 2.x.y being the major version now anyway, the next release should be 2.14. Lets stick with our convention until we have something that we really do want to promote to users outside the existing development community, I expect that will be a few years away yet. Laurence
On Tue, 5 Jul 2011 12:10:35 +0100 Laurence Rowe <l@lrowe.co.uk> wrote: Hello,
I agree with Jonas that any idea of giving a package named Zope2 a version number that is not 2.x is only going to lead to more confusion. For Zope2 we're used the x in 2.x.y being the major version now anyway, the next release should be 2.14. Lets stick with our convention until we have something that we really do want to promote to users outside the existing development community, I expect that will be a few years away yet.
I fully agree with that. A major version of Zope 2 is actually a minor at the version meaning, but everybody knows that for instance to switch from 2.10 to 2.11 you have to review and update your code like if it was a real major version change at the version meaning. That would be really confusing to do otherwise, since it was like that for years. I am also in favor of dropping the 2, but picking a new name would be nice, like to have 'framework x' 10 that map to Zope 2 2.10, 'framework x' to 2.11. Other products did that, Solaris, Mac OS X ... it is not strange to do so I think. Regards, Sylvain, -- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands
On 07/05/2011 12:22 PM, Jonas Meurer wrote:
Since we don't market Zope2 anymore, I think there's actually much less confusion from this than we'd fear. It's just an internal version number used in some buildout files, not something that has any particular meaning.
I don't like either of these solutions. And I don't agree with Hanno, that it's 'just an internal version number'. It will show up on zope.org, launchpad.net, and many more places.
I would rather bump the version number to 2.20 to highlight the major changes, and keep the 2 as major for Zope2 versions.
I agree calling it Zope 2 version 3 would be very confusing. There's a lot of Zope 3 google juice around that would get muddled up even more. Concerning not marketing Zope 2, heh, Zope and marketing strategies? I thought we were going to call "Zope 2", "Zope" now, so people will obviously be curious about this Zope thing... Never make any assumptions about a coherent Zope marketing strategy! I'll also drop in a reference to the existence of zope2.zope.org. Regards, Martijn
On 7/6/11 13:41 , Martijn Faassen wrote:
Concerning not marketing Zope 2, heh, Zope and marketing strategies? I thought we were going to call "Zope 2", "Zope" now, so people will obviously be curious about this Zope thing... Never make any assumptions about a coherent Zope marketing strategy! I'll also drop in a reference to the existence of zope2.zope.org.
I totally agree. Now would be a good moment to make it all a little better by dropping the name "Zope 2" in favor of "Zope". And I sincerely hope that "zope2.zope.org" will go away and its content end up on the new www.zope.org site. jens
On Wed, 06 Jul 2011 15:07:35 +0200 Jens Vagelpohl <jens@dataflake.org> wrote: Hello,
I totally agree. Now would be a good moment to make it all a little better by dropping the name "Zope 2" in favor of "Zope". And I sincerely hope that "zope2.zope.org" will go away and its content end up on the new www.zope.org site.
I would be very happy if this happens too. Regards, Sylvain, -- Sylvain Viollon -- Infrae t +31 10 243 7051 -- http://infrae.com Hoevestraat 10 3033GC Rotterdam -- The Netherlands
On 7/5/11 11:56 , Martin Aspeli wrote:
On 5 July 2011 10:31, Hanno Schlichting<hanno@hannosch.eu> wrote:
So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or 5.0 or anything else doesn't make it any better at all. So 3.0 is the most sensible one :)
Boy, that's going to be confusing. :)
I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the defunct Zope 3, although I don't think there are any particularly good options here.
I actually think it's a brilliant idea to "skip" 3.0 and call it 4.0. As Martin said, the potential for confusion is very high. A 4.0 would not only steer around confusing Zope3 3.x and Zope2 3.x, it would also make it easier to move back to the simple "Zope" moniker without any qualifying number tacked on. People who only look at version numbers would now choose Zope 4.0 instead of falling into the "unmaintained" Zope3 trap. jens
On 5 July 2011 11:10, Jens Vagelpohl <jens@dataflake.org> wrote:
On 7/5/11 11:56 , Martin Aspeli wrote:
On 5 July 2011 10:31, Hanno Schlichting<hanno@hannosch.eu> wrote:
So we just got ourselves a Zope2 version 3.0. And no, naming it 4.0 or 5.0 or anything else doesn't make it any better at all. So 3.0 is the most sensible one :)
Boy, that's going to be confusing. :)
I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the defunct Zope 3, although I don't think there are any particularly good options here.
I actually think it's a brilliant idea to "skip" 3.0 and call it 4.0.
As Martin said, the potential for confusion is very high. A 4.0 would not only steer around confusing Zope3 3.x and Zope2 3.x, it would also make it easier to move back to the simple "Zope" moniker without any qualifying number tacked on. People who only look at version numbers would now choose Zope 4.0 instead of falling into the "unmaintained" Zope3 trap.
I would tend to agree, given that we now have Blue Bream. Martin
On Tue, Jul 5, 2011 at 12:10 PM, Jens Vagelpohl <jens@dataflake.org> wrote:
On 7/5/11 11:56 , Martin Aspeli wrote:
On 5 July 2011 10:31, Hanno Schlichting<hanno@hannosch.eu> wrote: I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the defunct Zope 3, although I don't think there are any particularly good options here.
I actually think it's a brilliant idea to "skip" 3.0 and call it 4.0.
Ok, seems 4.0 is the more popular choice. We'll use that than and make Tres proud (http://www.palladion.com/home/tseaver/obzervationz/2009/zope-4.0-project - though zopefour.org has been taken over by a link farm). Hanno
On 7/5/11 14:41 , Hanno Schlichting wrote:
On Tue, Jul 5, 2011 at 12:10 PM, Jens Vagelpohl<jens@dataflake.org> wrote:
On 7/5/11 11:56 , Martin Aspeli wrote:
On 5 July 2011 10:31, Hanno Schlichting<hanno@hannosch.eu> wrote: I'd actually favour calling it Zope2 4.0 just to avoid any mix-up with the defunct Zope 3, although I don't think there are any particularly good options here. I actually think it's a brilliant idea to "skip" 3.0 and call it 4.0.
Ok, seems 4.0 is the more popular choice.
We'll use that than and make Tres proud (http://www.palladion.com/home/tseaver/obzervationz/2009/zope-4.0-project - though zopefour.org has been taken over by a link farm).
"zopefour" as a domain isn't very helpful. It would add yet another "top-level" name to the existing list (Zope 2, Zope 3). In the best of all possible worlds the package now known as "Zope2" would simply be "Zope", and its website is at www.zope.org. "Zope" is making the jump from version 2.x to 4.0. jens
On Tue, Jul 5, 2011 at 2:44 PM, Jens Vagelpohl <jens@dataflake.org> wrote:
"zopefour" as a domain isn't very helpful. It would add yet another "top-level" name to the existing list (Zope 2, Zope 3).
That was an April fools joke I was referring to. I didn't mean to suggest to actually use that in any way ;-) Hanno
Am 05.07.2011, 14:44 Uhr, schrieb Jens Vagelpohl <jens@dataflake.org>:
"zopefour" as a domain isn't very helpful. It would add yet another "top-level" name to the existing list (Zope 2, Zope 3). In the best of all possible worlds the package now known as "Zope2" would simply be "Zope", and its website is at www.zope.org. "Zope" is making the jump from version 2.x to 4.0.
+1 Logically Zope 2.12 would have been a major release due to eggification and dropping Python 2.4. Only makes sense to make label the next major version as such rather than pretending with 2.x that only minor changes are being made. As I've been able to do little or no development this year thanks to Leonardo for raising this and Hanno for his explanation. I do think a public roadmap, with opportunities for people wanting to get involved would be a good idea. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
On Tue, Jul 5, 2011 at 14:41, Hanno Schlichting <hanno@hannosch.eu> wrote:
Ok, seems 4.0 is the more popular choice.
I don't agree. Let's go with Fibonacci and call the next release Zope 8, as the logical extension of the series 1, 2, 3, and 5! :-P -- Martijn Pieters
Martijn Pieters wrote:
On Tue, Jul 5, 2011 at 14:41, Hanno Schlichting<hanno@hannosch.eu> wrote:
Ok, seems 4.0 is the more popular choice.
I don't agree. Let's go with Fibonacci and call the next release Zope 8, as the logical extension of the series 1, 2, 3, and 5!
How about ZopeNG? Waiting-for-some-beating, Andreas
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@hannosch.eu> wrote:
On Sun, Jul 3, 2011 at 1:03 AM, Leonardo Rochael Almeida <leorochael@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
Something of a meta-comment on this thread: It sounds like people are broadly in agreement on the direction, but not communicating enough about what's actually going on. I think it would be useful to keep some kind of roadmap wiki on zope.org, or at least post to the list periodically saying, "this is what we're about to start doing". Martin
On 4 July 2011 13:04, Leonardo Rochael Almeida <leorochael@gmail.com> wrote:
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.
The BlueBream URL syntax is no better than the existing VHM syntax, it makes for insanely complex proxy configs. The repoze.vhm approach of using headers is much, much simpler. However we choose to integrate it (whether as middleware or some other way,) lets at least use the simple approach of setting headers or hard coding in paste/whatever config. Laurence
On Mon, Jul 4, 2011 at 2:04 PM, Leonardo Rochael Almeida <leorochael@gmail.com> wrote:
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.
I tried to be careful to make things optional in the past. But we have reached the end of where that is possible in many ways. Yes, we can still make the session/browser id machinery optional, as these are in separate packages and the application setup code no longer depends on them. But almost everything else is all tightly integrated and part of the App, OFS and Zope2 packages. There's some code we can move out of these, like App.Extensions can go into ExternalMethods and ZSQLMethods - but there's not much else left that's actually independent.
- 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.
DTML is a standalone distribution, so I don't see any problem with it being used independently. I think we can move the App.special_dtml.DTMLFile class over to the DocumentTemplate distribution to make that easier.
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.
Indeed. The control panel basically is a view these days. I think there might be one or two "profilers" out there which add entries there as well. All of these should be easy to change and move to the application root. I've been especially annoyed by the profilers, which all left broken objects in the control panel, without any UI to remove them.
But, for example, you committed some changes (and todos) relating to removing icons. Out of curiosity What is the reasoning behind this?
Icons don't add any functionality as such, so there were rather easy to remove, following my premise that all of the ZMI should go sooner than later. There's no really good technical reason to remove them - if the ZMI should go we just have to start somewhere. Hanno
participants (15)
-
Andreas Jung -
Charlie Clark -
Chris McDonough -
Hanno Schlichting -
Jens Vagelpohl -
Jonas Meurer -
Laurence Rowe -
Leonardo Rochael Almeida -
Marius Gedminas -
Martijn Faassen -
Martijn Pieters -
Martin Aspeli -
Sylvain Viollon -
Wichert Akkerman -
yuppie