[Zope-dev] direction

[Sylvain Viollon]

On Sun, 03 Jul 2011 01:09:17 -0400
Chris McDonough <chrism at 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