As far as I know there are at least two (major) db systems that support asynchronicity, PostgreSQL via psycopg2 and MongoDB via pymongo, and that's good. If WSGI is capable of being asynchronous (I'm not very familiar with the internals of the protocol), even if that only requires the ready state token (or the fd identifier in environ for requests), that's good news.

I hope the interest among wsgi devs will rise as websockets become standardized, though. While websockets would have very specific use (also replacing current "semi-duplex" implementations via, say, Comet), there would still have to be single interface specification for integration with "traditional" web applications, because running two inherently incompatible systems within the context of a single web application is an integration nightmare.

Oh, btw, and let's not forget the infrastructure required with the advent of WebGL. Somehow I'm convinced that async-only web apps and interface specification should become the norm, rendering traditional (wsgi?) apps obsolete just like fastcgi, scgi and wsgi obsoleted cgi.

It would be nice if we didn't have to build entirely new frameworks from scratch because WSGI can't fit the async paradigm.

.oO V Oo.


On 03/15/2011 10:54 PM, Mike Orr wrote:
There has been an ongoing discussion between the WSGI developers and
Twisted about how to be more compatible. The upshot is that
asynchronous servers need some kind of token in the output stream that
means "I'm not ready; come back later." Other middlewares would have
to pass this token through unchanged. And of course, the application
would have to use non-blocking libraries such as non-blocking database
executors. I'm not sure if ordinary file access is "blocking" enough
to require that too.

The upshot has been that Twisted runs WSGI applications in a thread
anyway because it can't be sure they won't block. And there hasn't
been enough interest from WSGI developers to actually pursue using it
with asynchronous servers.

I think Python has a future object now which standardizes Twisted's
Deferred and the equivalent in other asynchronous servers. So that's a
start.

--
You received this message because you are subscribed to the Google Groups 
"pylons-devel" group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to 
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/pylons-devel?hl=en.

Reply via email to