[Web-SIG] Web Container Interface

[Phillip J. Eby]

At 03:31 PM 1/23/04 -0600, Ian Bicking wrote:
>Well, I was thinking of the "parsed" representation of headers being a 
>dictionary, or a list of two-tuples.  Systems that speak HTTP directly 
>will want access to these, so they can do all the CGI-ish stuff necessary 
>(translate the Status header to the response code, look at 
>Location).  They can re-parse the headers on the way out, or they could be 
>provided with the headers directly.  Seeing as most frameworks collect the 
>headers directly, it might be nice to save the trouble of serializing the 
>headers and then parsing them, at least when possible.

Maybe it would help if I rephrase one of my goals for WCI 1.0: *no existing 
app may be left behind*.  There are *plenty* of existing apps and 
frameworks that expect to send headers over the output stream for external 
parsing.  Making the interface used pre-parsed headers or no-parse headers 
would strand those applications in the pre-WCI world, or force everybody to 
write header parsers.  In my view, that simply voids the point of having 
the interface in the first place.


>Well, the application may want to share configuration with other 
>applications (even if it's where-do-I-find-my-configuration-file 
>configuration).  This could be container-wide, so the application could 
>query the container for that information.

That seems to me like straying into general component framework 
territory.  PEAK and Zope X3, for example, (and no doubt many more systems) 
have their own notions of how to share that kind of information.  WCI 
should be agnostic about that.


>Or, the application may want to know something about the URL layout. 
>Mmm... which makes me think that PATH_INFO and SCRIPT_NAME need to be well 
>defined for runCGI, or alternate variables need to be considered. Does 
>SCRIPT_NAME (and several associated CGI variables, PATH_INFO included) 
>point to the application, or the container, or what?

An excellent point.  That *should* be added to the spec.  I simply assumed 
they point to the object that is receiving the runCGI() call.  It should be 
made explicit, though.  Thanks!


>The application may want to know if there are any shared services it can 
>use, like a persistent storage for sessions, or a cron-type service. 
>Scheduling tasks particularly comes to mind -- it has to be done very 
>differently depending on the environment.  In a long-running threaded 
>environment you could probably do it yourself.  In an async environment 
>there's a specific callback that's part of the control loop.  In a 
>process-based environment you may have to talk to some parent process. In 
>a CGI environment... well, you just don't get one there.

Again, this is totally the job of an application framework, and will result 
in an instant religious war to try and put it in what ought to be a nice 
narrowly defined interface.  It should be more like a power outlet, and 
less like an ethernet jack.  :)


>Maybe I'm not entirely sure either.  Something's bothering me, though. I'm 
>having a hard time picturing the use of this proposal to do things we 
>can't do now, i.e., hooking up things that weren't built with each other 
>specifically in mind.

I have applications that run on ancient versions of ZPublisher that run as 
happily under my WCI containers as they do under straight CGI or in 
ZServer.  I imagine I could run them under a Webware container if there was 
one, or a mod_python container, or whatever else.

If that's not "things that weren't built with each other specifically in 
mind", I don't know what is.

Granted, in each case a few lines of glue code are required, to create the 
container and create the app.  And if a library doesn't already have a WCI 
container or app wrapper available, you have to write those too.

But that's a *lot* better than having to figure out from scratch how to 
connect two things today, if you can connect them at all.  And, if somebody 
writes a WCI router, you should be able to use multiple apps in the same 
process.  Indeed, people can write many different WCI routers, allowing 
them to use different mechanisms to find apps.


>That's what I was conceding.  We aren't ready to define what those 
>interfaces will be, but we need to keep in mind that there *will* be other 
>interfaces, and that the growth of those interfaces is important to the 
>utility of the WCI.  Simply passing in the container as an argument to 
>runCGI is probably sufficient.

Actually, I think it's more likely that a WCI 2.0 would grow another 
method, similar to the Java servlet 'init()' method, to tell the app that 
it's being "used by" a particular container.  However, at that point we'll 
also want to know something about what people actually want to get from a 
container, if anything.