[Web-SIG] Web Container Interface

[Phillip J. Eby]

At 10:28 PM 1/26/04 -0600, Ian Bicking wrote:

>That's true, but I think the services should be able to query the gateway 
>as well.  I part because the "inside" of the application, where you start 
>to battle portability issues, is likely to occur in the services.

I'll address that below.


>Gateways aren't all the same.  They just aren't.  Gateways can't and won't 
>be uniform.  They can't attempt to be uniform except by taking on an 
>every-expanding set of responsibilities.

Whaaa?  I now have three gateways I've written.  One is based on 
BaseHTTPServer, one uses CGI, and one uses FastCGI.  They're uniform.  All 
they do is call aService.runCGI().  Sure, they vary in how they get the 
data, what kind of file-like objects they pass to runCGI, and so on.  But 
none of that affects the services that run under them, which rely only on 
WSGI-guaranteed properties of those objects.

Perhaps we aren't in agreement on what "same" and "uniform" mean.  Or 
perhaps it's what "gateway" means that we're not agreeing on.  What I mean 
by "gateway" is, "source of HTTP requests and target of responses", and 
that is *all*.

If we ignore gateways that are also services (like request routers), then 
there it's likely that there will be *very* few gateway implementations to 
begin with: typically one per HTTP server type, plus a few for gateway 
protocols like CGI, FastCGI, SCGI, etc.  Given that many frameworks 
implement protocol gateways internally, we may initially see many competing 
protocol-based gateways, as framework developers are unlikely to want to 
tell their users to go find a gateway somewhere else.

The other type of gateway one may see is request routers that mangle 
'environ' and select a service to run, or pre/post-processors that replace 
stdin or stdout and .  As long as these conform to the interface, this is 
still "uniform" in my view.


>No, I'm thinking of the application/service as a framework as well.
>But I just don't see how a framework can fit into such a minimal interface 
>and still be portable.

Because nearly every single framework that exists right now is able to run 
under a CGI-like protocol.  And because *every* one of them is based on 
HTTP, and CGI is a reasonably straightforward and reversible mapping from HTTP.


>   For instance, how do I implement sessions?  I don't see a portable way 
> to do that in the service given this interface.  I don't even see an 
> unportable way to do it.

If you were writing a plain CGI, how would you implement sessions?  That's 
precisely how you'd do it here.  And any existing framework that does 
sessions for HTTP is mappable to this.  For example, my 6-years-old 
ZPublisher app that's cranking out 4 million dynamic pages or so per month 
under this interface, uses cookies.  It uses a Zope HTTPResponse object, 
calling 'setCookie()', and it reads the cookie from an HTTPRequest object.

Now, the top level service object passed to the gateway knows nothing of 
these details.  It simply calls Zope's 'publish()' function with the 
'stdin', 'stdout', 'stderr', and 'environ' provided by the 
gateway.  Everything below that is a plain ZPublisher application, that has 
been run via a variety of mechanisms over the years.  Neither the service 
nor the app care about each other's details, and the service doesn't care 
what kind of gateway is running it.  I've run it under a variety of 
gateways, and as long as the gateway conforms to the interface, everything 
below there is just fine.


>   Unless you propose that the code to add the service to the gateway 
> should include all sorts of options to cover all the particular 
> details... but I don't see how that will help any.

It's a way to get from HTTP to an *existing* web app framework.  Not a new 
framework.