[Web-SIG] Web Container Interface

[Jacob Smullyan]

On Wed, Jan 28, 2004 at 10:19:22PM -0600, Ian Bicking wrote:
> Wouldn't it be sufficient to close the stdout stream?  This could be 
> done before runCGI returns, and would (I presume) signal that execution 
> had completed.  Though that should be explicit.  

It would be sufficient, provided that closing stdout really meant
closing stdout and transmitting the http response.  Yes, what I said
about flush() should probably really apply (if it should at all) to
close(), not flush().

> Obviously some 
> containers (ack, too many alternative terminologies at this point) will 
> not be able to finish the request until after control has been returned 
> from runCGI, but I don't see how that can be helped.

It may be true that it can't be helped -- but it isn't obvious to me,
yet.  Is there anything about the assumptions of some frameworks that
would prevent a file-like object they are writing to from doing some
networking when they close it?  I would think that is the business of
the container, not the containee.  Or do you mean that the container
may be in turn nested in a preexisting environment, not optimized
specifically for this sort of containment, to which it delegates its
networking responsibilities -- the "run Zope inside WebWare" scenario?
That kind of scenario shouldn't be a sticking point, in my view,
because it will always be suboptimal.  If you want coexistence of two
different application environments, I'd expect to do better nesting
them both in one shared container which has limited, specialized
functionality than arranging them serially (Zope running inside
WebWare running inside SkunkWeb running inside...).  A lower level of
compliance, for such "convenience serial containers", would be
forgiveable.

 
> In general, fewer gateways would have to buffer output until after 
> control was returned, if headers weren't included in the output stream. 
>  You could parse the headers at the soonest moment, and then connect 
> the application to the actual client in a more direct fashion after 
> that time.  I suppose that only requires looking for \n\n (or a chunk 
> that ends in \n, and another that starts in \n), but it's still 
> annoying.  Anyway, if a container sends the complete request when 
> stdout.close() was called, control would at least temporarily be passed 
> to the container, while the application would still have a chance to do 
> some processing after stdout.close returns, and before runCGI returns.  
> Maybe those semantics -- or even a lack of required semantics -- should 
> be included in the PEP.

Yes, that is really what I'd like to see clarified.  At the very
least, a container should announce whether its output object really
outputs when it says it does.  

My focussing on flush() rather than close() was the wrong emphasis.
The reason I made that mistake was that I assumed that the container
was not in the business of worrying about http, but that that was the
responsibility of an adapter sitting between the application proper
and the container (that the container was in no-parsed-header mode, in
cgi terms); in that case, the container has no reason not to flush
when the client toggles the handle, rather than waiting for him to get
off the pot.  Upon reflection, I think the container *should* parse
headers by default -- what a bore for every adapter to have to do
this.  However, it would be nice if in runCGI you could set an
attribute of output that would tell it whether to parse headers or
not; it would seem reasonable to at least aspire to the range of
functionality already implemented by CGI :).  But I don't know if
Mr. Eby wants his nice abstract output object mucked up with pesky
attributes!  (This suggests a T-shirt: "Get your attributes off my
object!" -- "attributes" being more polite, if less general, than
"members".)

Cheers,

Jacob Smullyan
















> 
> --
> Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
> 
-------------- 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/20040129/0608e763/attachment.bin