[Web-SIG] Web Container Interface

[Jacob Smullyan]

On Wed, Jan 28, 2004 at 04:39:22PM -0600, Ian Bicking wrote:
> Phillip J. Eby wrote:
> >At 02:11 PM 1/28/04 -0600, Ian Bicking wrote:
> >>SkunkWeb also uses multiple processes, run in a separate space from 
> >>Apache.
> >
> >
> >How does it communicate with Apache?  Does it *require* multiple 
> >processes, or *allow* them?
> 
> It's like Apache, preforking worker processes.  It communicates with 
> mod_skunkweb, which is equivalent to FastCGI, PCGI, SCGI, mod_webware, etc.
> 
> It requires a single request per process (or a single process per 
> request) as it uses globals in several places, including print.  I don't 
> believe it offers any significant configuration of its behavior (number 
> of processes and such, but there's no threaded option or anything like 
> that).

SkunkWeb currently assumes and requires a multiple-process model, but
there is a plan to refactor it for 4.0 so that most of the code could
be used independently of that model, at least in threaded contexts,
and provide a choice of containers.  

One part of the PEP (which I may be looking at in an older version)
that attracted my attention:

3. Since ``output`` and ``errors`` may not be rewound, a container is
    free to forward write operations immediately, without buffering.
    In this case, the ``flush()`` method may be a no-op.  Portable
    applications, however, cannot assume that output is unbuffered
    or that ``flush()`` is a no-op.  They must call ``flush()`` if
    they need to ensure that output has in fact been written.

    Luckily, the use of ``output.flush()`` is only an issue for
    applications performing "server push" operations, since closing
    ``output`` will also flush it.  Applications writing logs or other
    output to ``errors``, however, may wish to perform a flush after
    each complete item is output, to minimize intermingling of data
    from multiple processes writing to the same log.

One useful feature of SkunkWeb is that it makes it easy to have work
performed after a response is sent, rather than before -- refreshing
caches, rolling back database connections, etc.  This is a
considerable benefit in http, since requests are by their nature
sporadic, and the crunch times are during request processing.  The
container interface proposed offers only one hook for a web
application (or whatever you want to call it) to do everything it is
going to do.  Therefore, the only way to ensure that work is performed
after the response is sent is to flush or close output before
undertaking that work.  I'd be happier, therefore, if the
specification mandated more explicitly that the container must
actually respect the semantics of flush() -- that flush() may be a
no-op if output is unbuffered, but it may not be a no-op if it is not.
This means that output, for instance, could not be a StringIO object
the contents of which the container blits back to the client after
runCGI() returns.  (It is debatable whether the error stream should be
subject to this limitation; it might even be preferable for some
containers to buffer error until after runCGI() has been completed.)

Cheers,

Jacob Smullyan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.python.org/pipermail/web-sig/attachments/20040128/b4b40b44/attachment-0001.bin