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 )
