On 07 June 2001, Andrew Kuchling said:
> I've just checked the following in as doc/programming.txt.
> Comments?
>
> And is there anything else that needs to be done before
> we can make a 0.3 release?

I think the biggest outstanding problems are:
  * logging doesn't work with CGI scripts (something about our
    log-opening code depends on how fastcgi.py fiddles stdout)
  * we should ditch Zope's HTTP{Request,Response} classes
    and write our own

I don't think either of these should stand in the way of releasing the
damn thing.  I think it should be said somewhere that running as plain
CGI doesn't work very well yet and will be addressed in a future
release.

Also, I would like to tweak some of the docs you've written, but I'm
going away for the weekend (in about an hour), so won't have time to do
that before Monday at the earliest.  If you want to release this
weekend, oh well -- I can always tweak the docs later.

BTW, I've already starting writing HTTPRequest, but got bogged down
because I don't really understand multipart form data, and the
interactions between Python's cgi.py and Zope's HTTPRequest are, shall
we say, intricate...

Oh yeah, comments on programming.txt:

> 1) A FastCGI script, usually called books.fcgi.  This script will
                       ^^^^^^^
"in this case" would be more apt

You might want to say a little more about the sample app up-front apart
from its name.

A sample app that deals with books is likely to deal with publishers: I
can see someone getting very confused over the Quixote "publisher"
object and the (presumed) 'publisher' attribute of Book objects.

>    FastCGI isn't an absolute requirement.  It should be trivially easy
>    to run Quixote apps using regular CGI, but this would be quite slow
>    due to the number of modules that need to be imported at startup
>    time.  We haven't tried to run Quixote under mod_python/mod_snake,
>    but it shouldn't be too difficult; if you try it, please let us
>    know how it goes.

Fiddlesticks -- vfab.fcgi is slow in RUN_ONCE mode because we have
33,000 lines of code in our system, the overhead of connecting to a ZEO
server, an object database with 70,000 objects in it, etc.  SPLAT! (with
1,000 LoC and a private Berkeley DB file) is just fine in RUN_ONCE mode,
and that's a much more realistic model of the kind of app people are
going to be throwing together.  Plain old CGI will work just fine for
small apps on fast servers... except for the fact that Quixote is buggy
for plain old CGI right now.

> 2) A configuration file, usually called books.conf.  This file sets
                           ^^^^^^^
"in this case" or similar wording again

> FastCGI script
> ==============
>
> The FastCGI script can be very simple:
>
>         books.fcgi
>       ----------
> #!/usr/bin/python

On most Linux boxen today, this is Python 1.5.2... and Quixote requires
Python 2.0.  Better state that somewhere!

Just skimmed the rest.  I would remove references to the MEMS Exchange
(apart from boasting about the size and complexity of the problem, since
Quixote has been a real boon in dealing with it) -- nobody knows what
the hell a MEMS process sequence is, and wondering about it isn't going
to help them write web apps.

        Greg
--
Greg Ward - software developer                gward@mems-exchange.org
MEMS Exchange                            http://www.mems-exchange.org