[Web-SIG] Web Container Interface

[Ian Bicking]

I'm afraid I hadn't kept up with Web-SIG back when this came up, but 
maybe that's okay since the topic seems to need revisiting anyway, since 
  the topic has been pretty quiet for a while.  So... what's the status 
of Phillip's web container proposal?


The biggest issue I see with it is that the container needs to be passed 
as one of the arguments to runCGI.  This allows for greater integration 
of the application and the container.  Blech... I don't like those 
terms, because the container's primary responsibility isn't containment, 
and the application's function is probably more general than a web 
application's.  I'd rather see the container called something like the 
HTTP Driver, or otherwise indicating that it is the bridge between this 
simplified CGI interface, and the full HTTP interface.  It may provide 
an HTTP interface, like with Twisted, or it may simply be a bridge to 
Apache or another server.  Container means nothing to me.  But I digress...

The interface is sparse, and doesn't allow for things like leaving 
headers parsed (which is something several containers would prefer). 
That's okay, but it would be nice -- even if only in an ad hoc manner -- 
if applications could query the container about what it is and how it 
works.  To do that we need to pass some sort of reference to the 
container, even if the nature of that object remains undefined.


The other (related) issue I see is the reliance on configuration.  One 
of the goals, presumably, is that frameworks that encompass both 
container and application (as Webware does) partition themselves more 
clearly.  That's no big deal -- Webware already has a function very like 
runCGI (Webware.WebKit.Application.dispatchRawRequest), and translating 
the method signatures is trivial.

Unfortunately, the real effort is in allowing it all to be "configured" 
to work with different backends, or the backend with different 
applications.  This reliance on configuration seems very Java.  I hate 
configuration.  A lot.  It makes programmers into system administrators, 
to the detriment of both programmers and system administrators.

If I was going to provide configuration for the Webware AppServer to be 
used with another application, or the Webware Application to be used 
with another container... well, I haven't figured out what I'd do.  I 
would probably define a richer interface for both container and 
application, and then possibly provide configuration to provide that 
interface when the container or application doesn't natively provide it 
(and the AppServer and Application would both provide that interface, so 
that Webware's internal integration would remain configuration free).

Perhaps this richer interface is the sort of thing we should be 
developing on an as-needed basis, like I would do for Webware, and 
hopefully as others did the same we'd informally start to agree on what 
that might look like.  And frankly, until this interface *is* developed, 
I don't think runCGI alone is a useful interface.  But it's a place to 
start.

Anyway, those are my thoughts.