[Web-SIG] Web Container Interface

[Ian Bicking]

On Jan 23, 2004, at 6:36 PM, Phillip J. Eby wrote:
> 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.

I'm not proposing that applications be required to implement a richer 
interface than what WCI 1.0 currently requires.  Rather, that 
applications be given the opportunity to implement a richer interface, 
even if we don't give any indication (in the PEP) of what that 
interface would be.

>> 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.

These are use cases, not things I think need to be in WCI 1.0.  We 
should work towards making these things possible -- which means we 
should leave room for WCI implementations to define their own 
interfaces that work in this direction.

>> 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!

Hmm... that might not be backward compatible.  In both Webware and I 
believe Zope (and probably several others) these point to the container 
root, not the resource root.  I would propose that these variables 
remain undefined, and that additional variables be added with better 
defined meaning.

>> 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.  :)

Again, I'm not proposing we set out a standard that covers these, but 
that we leave room for implementations to extend the standard to cover 
these cases.

>> 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.

I remain skeptical.  I can't really see how you'll run a Zope 
application under plain CGI, or how both a Zope application and a 
Twisted application could successfully run with the same interface.  I 
still can see that this is a step in the right direction -- not a big 
step, but it's still the right direction.

> 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.

I think WCI 1.0 needs an init(), or something equivalent (like simply 
passing the container in to runCGI()).  I think it is useful to provide 
that hook, even if we give implementors no specification beyond that.

A portable application might even go as far as doing:

if container.__class__.__name__ == 'AppServer':
     # Probably Webware, we'll do X
elif container.__class__.__name__ == 'ZPublisher':
     # Zope, we do Y
...

If that's what it takes for the author of the application to get things 
to work, so be it.  Portable applications in Python typically require 
some special cases as issues arise -- it's better to enable developers 
than to enforce agnosticism.  This is the distinction I would make 
between Python's approach to portability and Java's -- and I think 
Python is more successful in its approach.  Hopefully experience with 
these special cases can be used to specify container interfaces for WCI 
2.0.

--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org