At 09:07 AM 2/5/99 -0500, Jim Fulton wrote:

"Phillip J. Eby" wrote:

...

I hope in the next few days to tackle a multithreaded, 100% Python FastCGI front-end for ZPublisher. When it works, I'll share code, as I'd like to see it get back into Zope the way my CGI front-end code did. :)

ZServer *will* support FastCGI. I was thinking of doing this myself, but don't know when I'll get to it. You might consider working on the ZServer (Medusa) FastCGI support. It should be easier and will be more useful to others, I think.

I have an immediate need for the standalone FastCGI, though. Also, unless ZServer will be able to be configured to die off the way my standalone FastCGI support already does, ZServer won't be appropriate for my operating environment at present. Next, the standalone is an easier project for me to tackle first because it's just a grafting of an existing 100% Python FastCGI front-end onto ZPublisher with some threading glue. And finally, it'd be nice to have that PCGI example to look at first before tackling a ZServer publishing protocol. :)

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.