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 )
[Zope-dev] www.zope.org relaunch on Thursday
Hi there, www.zope.org will be relaunched this Thursday. The current www.zope.org will be moved old.zope.org and replaced with the new site. During the DNS transition and while working on the sites you may encounter outages. The transition will start on Thursday (Germany) morning. 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 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 )
[Zope-dev] zope-tests - FAILED: 1, OK: 84, UNKNOWN: 1
This is the summary for test reports received on the zope-tests list between 2011-07-03 00:00:00 UTC and 2011-07-04 00:00:00 UTC: See the footnotes for test reports of unsuccessful builds. An up-to date view of the builders is also available in our buildbot documentation: http://docs.zope.org/zopetoolkit/process/buildbots.html#the-nightly-builds Reports received Bluebream / Python2.4.6 64bit linux Bluebream / Python2.5.5 64bit linux Bluebream / Python2.6.5 64bit linux [1]UNKNOWN : Zope Buildbot / zopetoolkit-1.1_win-py2.5 slave-win ZTK 1.0 / Python2.4.6 Linux 64bit ZTK 1.0 / Python2.5.5 Linux 64bit ZTK 1.0 / Python2.6.5 Linux 64bit ZTK 1.0dev / Python2.4.6 Linux 64bit ZTK 1.0dev / Python2.5.5 Linux 64bit ZTK 1.0dev / Python2.6.5 Linux 64bit Zope 3.4 KGS / Python2.4.6 64bit linux Zope 3.4 KGS / Python2.5.5 64bit linux Zope 3.4 Known Good Set / py2.4-32bit-linux Zope 3.4 Known Good Set / py2.4-64bit-linux Zope 3.4 Known Good Set / py2.5-32bit-linux Zope 3.4 Known Good Set / py2.5-64bit-linux Zope Buildbot / zope2.12-py2.6 slave-osx Zope Buildbot / zope2.12-py2.6 slave-ubuntu32 Zope Buildbot / zope2.12-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.6 slave-osx Zope Buildbot / zope2.13-py2.6 slave-ubuntu32 Zope Buildbot / zope2.13-py2.6 slave-ubuntu64 Zope Buildbot / zope2.13-py2.7 slave-osx Zope Buildbot / zope2.13-py2.7 slave-ubuntu32 Zope Buildbot / zope2.13-py2.7 slave-ubuntu64 Zope Buildbot / zope2.13_win-py2.6 slave-win Zope Buildbot / zope2.13_win-py2.7 slave-win Zope Buildbot / zope2.14-py2.6 slave-osx Zope Buildbot / zope2.14-py2.6 slave-ubuntu32 Zope Buildbot / zope2.14-py2.6 slave-ubuntu64 Zope Buildbot / zope2.14-py2.7 slave-osx Zope Buildbot / zope2.14-py2.7 slave-ubuntu32 Zope Buildbot / zope2.14-py2.7 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.4 slave-osx Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.4 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.5 slave-osx Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0-py2.6 slave-osx Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.0-py2.6 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.0_win-py2.4 slave-win Zope Buildbot / zopetoolkit-1.0_win-py2.5 slave-win Zope Buildbot / zopetoolkit-1.0_win-py2.6 slave-win Zope Buildbot / zopetoolkit-1.1-py2.5 slave-osx Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.1-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.1-py2.6 slave-osx Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu32 Zope Buildbot / zopetoolkit-1.1-py2.6 slave-ubuntu64 Zope Buildbot / zopetoolkit-1.1_win-py2.6 slave-win Zope Buildbot / zopetoolkit-py2.5 slave-osx Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu32 Zope Buildbot / zopetoolkit-py2.5 slave-ubuntu64 Zope Buildbot / zopetoolkit-py2.6 slave-osx Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu32 Zope Buildbot / zopetoolkit-py2.6 slave-ubuntu64 [2]Zope Buildbot / zopetoolkit_win-py2.5 slave-win Zope Buildbot / zopetoolkit_win-py2.6 slave-win Zope-2.10 Python-2.4.6 : Linux Zope-2.11 Python-2.4.6 : Linux Zope-2.12 Python-2.6.6 : Linux Zope-2.12-alltests Python-2.6.6 : Linux Zope-2.13 Python-2.6.6 : Linux Zope-2.13-alltests Python-2.6.6 : Linux Zope-trunk Python-2.6.6 : Linux Zope-trunk-alltests Python-2.6.6 : Linux winbot / ZODB_dev py_254_win32 winbot / ZODB_dev py_265_win32 winbot / ZODB_dev py_265_win64 winbot / ZODB_dev py_270_win32 winbot / ZODB_dev py_270_win64 winbot / ztk_10 py_254_win32 winbot / ztk_10 py_265_win32 winbot / ztk_10 py_265_win64 winbot / ztk_11 py_254_win32 winbot / ztk_11 py_265_win32 winbot / ztk_11 py_265_win64 winbot / ztk_11 py_270_win32 winbot / ztk_11 py_270_win64 winbot / ztk_dev py_254_win32 winbot / ztk_dev py_265_win32 winbot / ztk_dev py_265_win64 winbot / ztk_dev py_270_win32 winbot / ztk_dev py_270_win64 Non-OK results -- [1]UNKNOWN UNKNOWN : Zope Buildbot / zopetoolkit-1.1_win-py2.5 slave-win https://mail.zope.org/pipermail/zope-tests/2011-July/045022.html [2]FAILED Zope Buildbot / zopetoolkit_win-py2.5 slave-win https://mail.zope.org/pipermail/zope-tests/2011-July/045024.html ___ Zope-Dev maillist - Zope-Dev@zope.org
