[Web-SIG] Web Container Interface

[Phillip J. Eby]

At 03:14 PM 1/30/04 -0600, Ian Bicking wrote:
>Sessions remain the use case I consider to be unresolved.  I think 
>sessions should be possible to implement portable, without requiring 
>configuration that specifies the gateway's process/concurrency model. 
>(That doesn't rule out configuration, just that in the absence we should 
>be able to pick the right implementation)
>
>Probably all this requires is a way to indicate the process model.

How about by indicating whether the application can be

1. Run in multiple processes
2. Run by multiple threads

as information exposed by the app?  Or do you think that we should have a 
"setup" method called by the container to tell the app what model it's 
going to be run under?


>Yes, my point was just that Twisted .rpy scripts and the like wouldn't fit 
>into the model.  Or, they could, but it would be kind of silly, since 
>you'd loose all the advantages of async, even if you ran under a Twisted 
>gateway.  In contrast, many other systems could be composed into gateway 
>and application without any real downside.

Right.  The goal for WSGI in the case of Twisted is to let people migrate 
apps *to* Twisted, not *from* it.  :)  I don't think that migrating from 
Twisted to anything other than another event-driven framework (e.g. 
peak.events) is even possible, and there aren't any mature alternatives 
with comparable capabilities to Twisted at the moment, if i understand 
correctly.