Is there a benefit of pcgi over using mod_proxy ?
There was. pcgi worked over a unix domain socket, and unix domain sockets can be compartentalized much easier than say, a tcp port. This means you could effectively use pcgi with a single apache instance fronting for several zope+pcgi instances in a virtual-hosting scenario. (I used mod_pcgi2 for this purpose.) This had several seperation advantages as you can then run the zope instances as different users, ensuring your zope vhosts have no ability to cross-contaminate eachother at the zodb level, plus it was easy to define a filesystem namespace for every vhost (all of customer Foo's files go in ~foo, nice and easy). What happened is that PCGI wasn't maintained and its scalability went to hell. Zope hosting companies, atleast the one I worked for, had to switch to mod_proxy because pcgi just fell over if you looked at it funny. That means virtual hosting then requires either managing a battery of internal interface aliases, or a map of ports on some internal interface, or throwing all your eggs into one basket (zodb). All of which are less than sexy, IMO. Unix domain sockets would be great, but apache has no way to forward requests to them that I know of, outside of custom modules. Apart from that, pcgi was about on par with mod_rewrite in terms of integration with Apache. Better integration could be possible if someone wrote a module that let zope speak directly to the Apache API. To date though people seem to be more enthralled with the idea of loosely connecting Zope and Apache at the protocol. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly