[Web-SIG] Web Container Interface
Phillip J. Eby
pje at telecommunity.com
Fri Jan 30 16:31:35 EST 2004
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
More information about the Web-SIG