Breaking this out as the thread has got overlong.
On 4 July 2011 09:49, Sylvain Viollon <sylv...@infrae.com> wrote:
> 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:
>> > - 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).
I was interested to see that Pyramid seems to be experimenting with a
non-wsgi approach now too for transaction integration
I really don't have enough experience with WSGI to know which is the
best way to do it.
I took a brief look at the documentation at
http://www.infrae.com/download/tools/infrae.wsgi where some of the
motivations behind it are mentioned. The builtin Zope2 WSGI publisher
is still very new, and seems to have some rough edges still when
running in mod_wsgi (possibly due to conflicts with Zope registered
signal handlers.) Is it only that you think that the Zope2 WSGI
publisher is not ready yet, or are there other problems?
I'd certainly support simplifying the publisher, it has grown very
complex as more and more functionality has been grafted on over the
years. In the long run I'd much rather see something that only used
__getitem__ for traversal and never getattr.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -