[Zope] - Serving Zope...

[Jeff Bauer]

  AS=Andy Smith
  AK=Andy Kuchling

AS>> With ZopeHTTPServer supplied as part of Zope anyway,
AS>> should support for Apache be that high a priority?

AK> Yes, it should.  I doubt that ZopeHTTPServer.py will
AK> support SSL at the same level as a commercial Apache
AK> variant such as Stronghold.  For commerce applications,
AK> the security aspect is important

I'd like to add that I think there's a commercial 
opportunity for a company that wishes to "harden" Zope's 
security.  For Zope to realized it's potential as an ORB, 
HTTP-RPC, or whatever you want to call it, we need 
SSL-enabled clients to work within the Zope framework.
Digital Creations, for instance, could sell certificates,
provide consulting, etc., if this were an area they
desired to enter commercially.  A company in a country not 
governed by U.S. ITAR restrictions might even do better.

AS>> Does the average Zoper actually use the preconfigured
AS>> Apache ... or does he/she use the installation to
AS>> figure out how to configure an existing server.

AK> Configure an existing server; I don't think I'll use
AK> ZopeHTTPServer except for the most trivial testing and
AK> experimentation.

I think the main reason we've seen a pre-configured apache
distributed with Zope is to provide an existence proof that
Zope can work with Apache's authorization scheme.  Since
mod_rewrite isn't compiled in by default in Apache (and
setting it up can be a hassle)  Digital Creations wanted 
to have something work out of the box.

I don't believe someone can run an Apache server for
very long without learning about Apache.  Many of the
problems we're seeing on the list (and privately) are
really Apache issues and have nothing to do specifically
with Zope.

AS>> How can pcgi be used to best effect?  Would an apache 
AS>> mod_pcgi be useful?

AK> Probably, though I don't know how high the traffic 
AK> would have to be before the time to execute the 
AK> pcgi-wrapper becomes a significant drain.  I suspect
AK> this isn't a high priority at the moment, because few
AK> people will do very high-traffic sites with Zope
AK> until they're familiar with the technology.  That
AK> should make for some delay before a mod_pcgi is needed.

I don't have the numbers, but Digital Creations staff can
attest that pcgi-wrapper scales well on Unix.  Much less
so on Win32.

Some specific issues regarding mod_pcgi:

1.  Should pcgi be in the process management business?
    There was some earlier discussion about this on the
    Bobo list.  It may be worth reaching some decisions
    before putting mod_pcgi into service.
    
2.  Server-specific issues.  One of the neat things about
    pcgi is its server independence.  A mod_pcgi module
    should preserve feature parity with pcgi-wrapper.
    
3.  Authorization.  A mod_pcgi module would probably
    eliminate most of the current authorization/mod_rewrite
    issues with Apache.  This is probably the single most
    useful feature mod_pcgi has to offer, far ahead of any
    performance gains (which nobody has complained about
    anyway, AFAIK).  Magnus Lie Hetland has also reminded 
    me that we face certain possible compromises here too,
    between security and usability.
    
4.  Maintainability.  Another neat thing about pcgi-wrapper
    is that it's simple to get into and figure out what's
    going on.  It doesn't matter that it's basically
    brain dead, leaks memory like a sieve, and can only
    guess when a process is ready for a connection.  The
    reason that it (usually) doesn't matter is that 
    pcgi-wrapper simply works (when it fails to function, 
    its failure is not because of the reasons above) and 
    it's easy to debug.
    
    Add some intelligence to pcgi-wrapper and make it an
    Apache extension, and you have a much more difficult
    time figuring out what's going on or how to go about
    fixing it.
    
I think mod_pcgi is a good idea.  It would be nice to
have pcgi out of the process management business before
mod_pcgi gets built, but there's nothing to say we have
to wait.  And I think for pcgi to get out of the process
management business ... nah, let's save it for another
thread.

Best regards,

Jeff Bauer
Rubicon, Inc.