[Web-SIG] Web Container Interface

[Phillip J. Eby]

At 12:57 PM 1/28/04 -0600, Ian Bicking wrote:
>Currently Webware's primary session mechanism keeps the session in memory 
>until the session reaches a certain age (likely because the user has gone 
>away), at which time the session is pickled and moved to disk, in case the 
>user comes back.  This is done with a scheduling service that is part of 
>Webware, as is the ultimate expiration (where the file is 
>removed).  Locking is handled with thread locks, because Webware expects a 
>single-process model.  Also, when the AppServer is shut down or restarted 
>(which can happen very often during development), all sessions are pickled 
>and written to disk.

So, it sounds like Webware would say that its services were only runnable 
under single-process gateways.  That sounds like a from-the-ground-up 
architectural decision.  It's not going to be runnable under CGI or 
mod_python, certainly.  But it *would* run in a single-process Python web 
server, or using FastCGI either as a dynamic app with maxclass=1, or as an 
"external" FastCGI app.


>So, there's an existing session mechanism.  The exact details of the 
>implementation don't have to be maintained, but the external interface and 
>semantics should be.  That involves:
>
>* Sessions that persist over multiple requests.
>* Sessions persist over server restarts.
>* Objects put into the session do not need to be stored in client-side 
>cookies.
>* Some concurrency protection (applications still need to consider their 
>own concurrency requirements).
>* Sessions are expired in a consistent, scheduled manner.
>
>Now, most of these can be implemented for CGI.  The last one would 
>probably be slightly different, in that there may or may not be a 
>scheduling service -- cron job or otherwise -- so an ad hoc scheduler that 
>runs whenever a session is fetched may be necessary.  But the 
>*implementation* would be significantly different depending on the 
>context.  Webware's currently implementation wouldn't work in CGI, and to 
>determine an optimal implementation it has to know something about the 
>environment it's being run in.

I understand where you're coming from, but the proposal isn't intended to 
make fish into birds or vice versa.  I'm pretty sure it was discussed 
previously that applications that assume a particular process model are 
only going to run in gateways that can provide that process model.  That's 
*still* more gateways than they can run in now!


>And, to make it a little harder, we've often had requests to implement 
>memory-only sessions, to put unpickleable objects into the session. 
>Usually we just tell people to keep these values in module globals.  But 
>module globals are also unportable across environments.

But if your framework only supports a "long running, single-process" 
architecture, module globals would work just fine with any gateway that 
supports that.

Frankly, "multi-process only" and "short running" gateways are going to be 
in the minority anyway.  The only gateway I know of that's likely to 
*require* multiple processes is mod_python, and the only gateway that's 
likely to be "short running" is plain CGI.  So, it's not like requiring an 
"LR/SP" gateway is going to dramatically limit the choice of gateways for 
Webware.

Obviously, the PEP needs to have examples of these process models added, 
and clarify the nature of the restrictions.  Who knows, maybe if we talk 
about this long enough maybe we'll be able to clarify the process models 
well enough to define a variable that services can expose to indicate their 
compatibility with various process models.

At that point, we almost might as well go ahead and make the API have all 
five Java servlet methods, call the objects servlets, and be done with it.  :)