[Web-SIG] Web Container Interface

[Ian Bicking]

Phillip J. Eby wrote:
> 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.

Specific Webware applications need a single-process model.  The 
framework as a whole could be used in a multi-process or short running 
model (and a short-running implementation exists), but it would be 
changed to write sessions out to disk immediately in that case, and use 
some sort of disk-based locking instead of thread locks.  But there's no 
reason to implement sessions that way when it's not necessary.

Portable Real Web Applications could also adapt their behavior depending 
on how they were being run, for instance creating an abstraction that 
cached data in module globals if available (and unlike sessions, that 
can work in multi-process models), or wrote them to disk otherwise.

In a long-running model, the framework also needs to know when the 
environment is shutting down (so it can write data out to disk).  Maybe 
atexit would be sufficient, I'm not sure (it's not what we use now).

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

But why not provide that one little hook (a link to the 
gateway/container) that would allow systems to develop greater 
portability?  (Hmm... when I think in terms of execution model, 
container seems much more appropriate of a term than gateway)

Ultimately, I see a significant goal to be the ability to run actual 
applications in multiple environments.  So Mailman (for instance) could 
run in its own space (Twisted), in Apache (mod_python), CGI, or 
something else entirely.  We shouldn't entirely ignore the applications.

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

SkunkWeb also uses multiple processes, run in a separate space from Apache.

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

I think that would be very useful.  Here's my list:

Single process per request:
* process ends with request (CGI, Webware OneShot)
* process reused (mod_python, SkunkWeb)

Multiple requests per process:
* Asynchronous (implied to be single-threaded) (Twisted, Medusa, 
CherryPy, BaseHTTPServer)
* Threaded (Zope, Webware, CherryPy with different settings)

Most asynch environments can be turned into threaded systems after 
runCGI.  Webware, at least, is threaded at the point runCGI is called 
(maybe to its detriment), but many systems are not (including Zope, I 
think, and probably CherryPy).

I believe most other frameworks are built on mod_python, CGI, or FastCGI 
so they are covered under these categories.  I think there might be a 
separate threaded model for quixote, but I don't know if that portion 
has its own name.  I'm not sure I understand FastCGI well enough to 
classify it.

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