[Zope] Zope and FastCGI

Phillip J. Eby pje@telecommunity.com
Fri, 05 Feb 1999 11:26:26 -0500


At 09:37 AM 2/5/99 -0600, Jeff Bauer wrote:
>"Phillip J. Eby" wrote:
>> And finally, it'd be nice to have that PCGI example to look at first before
>> tackling a ZServer publishing protocol.  :)
>
>One goal, I suppose, would be to have all LRP mechanisms editable
>from a single Zope.cgi file.  This would permit the user to adopt
>whatever is most convenient for their circumstances, e.g.
>
>  1) direct ZServer
>  2) direct PCGI
>  3) direct FCGI  (either cgi-fcgi, or mod_fcgi)
>  4) ZServer + PCGI | FCGI
>
>That being the case, we could work out a set of directlves
>for Zope.cgi that would be common to both approachs.
>Amos already has ZServer ignore specific PCGI directives
>that don't apply to Medusa.  This assumes that FCGI
>uses (or will use) Zope.cgi.
>

By Zope.cgi, do you mean ZCGI.py?  Or...?

I would like to standardize parameters, in any event.  So far, here are
some of the ones I know of:

Common:
=======
PUBLISHED_MODULE = 'name of module to publish'
INCLUDE_PATHS = ['paths/to/add','to/sys.path']


ZCGI.py
=======
Z_DEBUG_MODE = boolean
IIS_HACK = boolean


Launcher.py
===========
IDLE_TIMEOUT = # of seconds after which idle process dies
MAX_REQUESTS = retire process after # requests
MAX_LIFETIME = retire process after # seconds
PROCESS_LOCK_FILE = '/path/to/file/for/mutual/exclusion'
SOFTWARE_HOME = 'path/to/published/module'

Currently, Launcher handles SOFTWARE_HOME the way cgi-module-publisher used
to, i.e., it appends "Components" and "Components/sys.platform" to make
additional variants added to the INCLUDE_PATHS.  It also does all the
symlink sniffing and is fully (AFAIK) backward compatible with earlier Bobo
launchers.  It even defaults PUBLISHED_MODULE to the basename of sys.argv[0].

Now, in addition to all of the above, I've noticed that Zope 1.9 looks for
some variables in the environment, and others in __main__.  Perhaps what we
need is a "ZConfig" object that handles retrieving configuration parameters
automatically, looking first in __main__, then in os.environ, and finally
returning a caller-supplied default.  E.g.:

import __main__, os

class ZConfig:
	def __init__(self):
		self.__dict__.update(os.environ)
		self.__dict__.update(__main__.__dict__)
		self.get = self.__dict__.get

	def default(self,item,val):
		setattr(self,item,self.get(item,val))

__main__.__builtins__.ZConfig = ZConfig = ZConfig()

Now, you could say from anywhere:

ZConfig.default("Z_DEBUG_MODE",1)

to set a default, 

ZConfig.Z_DEBUG_MODE 

to retrieve the current setting, or:

ZConfig.get("IIS_HACK",0)

to retrieve a setting with an in-line default.

Once we had this, ZCGI and any other plumbing module could just import
ZConfig, set any additional defaults that were needed, and then chug right
along with the meat of the publishing process.

Thoughts anyone?  Seems like this would fit nicely in the ZPublisher
package as "import ZPublisher.ZConfig".  With a few more additions, it
could handle some defaults for the other things (e.g. SOFTWARE_HOME,
PUBLISHED_MODULE) as well.