[PYTHONMAC-SIG] Design of MacPython CGI interface

[Jack Jansen]

Folks,
I've gotten CGI scripts in Python to work, more or less, but now I'm
thinking of the final design of the interface and I'm stuck, so I'd
like some feedback.

On unix (and NT, and probably most other systems) Python CGI scripts
are run as "main program". They import the cgi module, use its
functionality to obtain the script parameters, send their resulting
document to stdout and terminate.

On the Mac, the situation is different. A CGI script is run and should
immedeately go into its eventloop. It will then receive a "do CGI
script" AppleEvent, which contains the script parameters. Then, the
script should execute and pass the resulting document back to the
webserver as the data in the AppleEvent reply. After this, the script
can either remain running (to wait for the next "do CGI script"
AppleEvent) or exit (in which case it will be restarted the next time
it is needed).

I can think of a number of ways to design the MacPython CGI interface:

1. Forget about compatability with Unix CGI scripts altogether. This
   would result in an interface something like

   import maccgi

   def myscript(args):
	rv = "Content-Type: blabla\n"
	rv = rv + blablabla
	...
	return rv

   maccgi.run(myscript)

2. Implement the above interface, and ask Guido to optionally support
   this interface for Unix/NT as well. (so people who use this
   interface get compatability, people who use the current unix
   interface don't).

3. Similar to (2), but implement some things in the Mac interface that
   would make it a bit more unix-like. The two things that come to
   mind are
   - in maccgi.run(), setup stdout to point to a file-like object so
     the "print" statement can be used for output generation
   - don't pass the arguments in the call to myscript() but use the
     cgi.FieldStorage() idiom used by the unix scripts (possibly
     augmented with stuffing things into sys.environ).
   The unix cgi.py would contain the routine

   def run(func):
	func()
   for compatability.

4. Make porting even easier for the unix buffs, by allowing the script
   code to be in the script body (in stead of in a separate routine,
   as in the three designs above). This would mean writing routines
   maccgi.start() and maccgi.end(), where the start routine would go
   into the eventloop until the "do CGI script" event was received,
   decode it, setup stdout as in (3) and return. End() would collect
   the stdout results and send them as AppleEvent reply.

5. Something else altogether.

I would personally favor solution (3), but Guido appears not too
willing to change cgi.py (although I can always hope, of course, that
this message will convince him otherwise). And, of course, it is
possible that people have brilliant ideas for (5), or that people
think CGI script portability isn't a worthwile issue.

What do people think?
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@cwi.nl      | ++++ if you agree copy these lines to your sig ++++
http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 

=================
PYTHONMAC-SIG  - SIG on Python for the Apple Macintosh

send messages to: pythonmac-sig@python.org
administrivia to: pythonmac-sig-request@python.org
=================