Re: [Zope-dev] direction
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On Tue, 5 Jul 2011 12:11:40 +0100 Martin Aspeli optilude+li...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
-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 tsea...@palladion.com Palladion Software Excellence by Designhttp://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- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On 5 July 2011 20:21, Leonardo Rochael Almeida leoroch...@gmail.com wrote: Hi Hanno, On Tue, Jul 5, 2011 at 11:18, Hanno Schlichting ha...@hannosch.eu wrote: On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli optilude+li...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On 6 July 2011 15:27, Sascha Welter zopel...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
Hi. On Tue, Jul 5, 2011 at 9:21 PM, Leonardo Rochael Almeida leoroch...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] direction
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:
Re: [Zope-dev] direction
On Tue, Jul 5, 2011 at 10:19 AM, Tobias Helfrich helfr...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On Mon, Jul 4, 2011 at 10:49 AM, Sylvain Viollon sylv...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On 5 July 2011 09:42, Hanno Schlichting ha...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On 5 July 2011 10:18, Hanno Schlichting ha...@hannosch.eu wrote: On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli optilude+li...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On Mon, Jul 4, 2011 at 12:19 PM, yuppie y.2...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On 5 July 2011 10:31, Hanno Schlichting ha...@hannosch.eu wrote: On Mon, Jul 4, 2011 at 12:19 PM, yuppie y.2...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On Tue, Jul 5, 2011 at 11:56 AM, Martin Aspeli optilude+li...@gmail.com wrote: On 5 July 2011 10:31, Hanno Schlichting ha...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On 7/5/11 11:56 , Martin Aspeli wrote: On 5 July 2011 10:31, Hanno Schlichtingha...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On 5 July 2011 11:10, Jens Vagelpohl j...@dataflake.org wrote: On 7/5/11 11:56 , Martin Aspeli wrote: On 5 July 2011 10:31, Hanno Schlichtingha...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
-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+li...@gmail.com wrote: On 5 July 2011 10:31, Hanno Schlichting ha...@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- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
Hi Hanno On Tue, Jul 5, 2011 at 10:19 AM, Tobias Helfrich helfr...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 05.07.2011 11:30, schrieb Martin Aspeli: On 5 July 2011 10:18, Hanno Schlichting ha...@hannosch.eu mailto:ha...@hannosch.eu wrote: On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli optilude+li...@gmail.com mailto:optilude%2bli...@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- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On 5 July 2011 11:22, Jonas Meurer jo...@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+li...@gmail.com wrote: On 5 July 2011 10:31, Hanno Schlichting ha...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
Hi, On 5 July 2011 11:26, Tobias Helfrich helfr...@know-it.net wrote: Hi Hanno On Tue, Jul 5, 2011 at 10:19 AM, Tobias Helfrich helfr...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On Tue, Jul 5, 2011 at 12:10 PM, Jens Vagelpohl j...@dataflake.org wrote: On 7/5/11 11:56 , Martin Aspeli wrote: On 5 July 2011 10:31, Hanno Schlichtingha...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
Am 05.07.2011, 14:44 Uhr, schrieb Jens Vagelpohl j...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On Tue, Jul 5, 2011 at 2:44 PM, Jens Vagelpohl j...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On Tue, Jul 5, 2011 at 14:41, Hanno Schlichting ha...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
Martijn Pieters wrote: On Tue, Jul 5, 2011 at 14:41, Hanno Schlichtingha...@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 attachment: lists.vcf___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On 7/5/11 3:22 AM, zope-dev-requ...@zope.org wrote: Hanno writes: Someone might try, but I think it's not a wise decision to spent any resources that way. I am trying. I am trying to create a Zope 2 like TTW development environment on top of BlueBream. I have a small email list of people who see the world this way. While many core ZTK developers do not like TTW development, there are many of us zope users who do like it. May a thousand open-source flowers bloom. I am making progress. I have ice.control and ZAM running. I have the ZMI running on Zope 3.something.But I am finding it very hard work.I learned quite a bit from this discussion, thank you. All I have to do is subclass the OFS with something that also inherits from acquisition. Cool. And then integrate all the ZMI code into ZAM. Then get the rest of the content types working. I am stuck on figuring out which page template in ZAM to edit. And I am stuck on figuring out how to fire up the ZMI in Bluebream. I will figure it all out.Or I will hire some of the Bluebream guys in eastern Europe to help me figure it out. In any case I now have a project that needs it, so I am motivated. -- Regards Christopher Lozinski Check out my iPhone apps TextFaster and TouchTexting http://textfaster.com Expect a paradigm shift. http://MyHDL.org ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
Hi Hanno, On Tue, Jul 5, 2011 at 11:18, Hanno Schlichting ha...@hannosch.eu wrote: On Tue, Jul 5, 2011 at 11:03 AM, Martin Aspeli optilude+li...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On Sun, 03 Jul 2011 01:09:17 -0400 Chris McDonough chr...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
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 signature.asc Description: Digital signature ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
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 ha...@hannosch.eu wrote: On Sun, Jul 3, 2011 at 1:03 AM, Leonardo Rochael Almeida leoroch...@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.
Re: [Zope-dev] direction
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On 4 July 2011 13:04, Leonardo Rochael Almeida leoroch...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
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 wich...@wiggy.net It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On Sun, Jul 3, 2011 at 7:09 AM, Chris McDonough chr...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On 3 July 2011 16:44, Hanno Schlichting ha...@hannosch.eu wrote: On Sun, Jul 3, 2011 at 7:09 AM, Chris McDonough chr...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
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 wich...@wiggy.net It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
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.txt I don't know of any other sessioning libraries. - C ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
On Sun, Jul 3, 2011 at 1:03 AM, Leonardo Rochael Almeida leoroch...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] direction
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
