On Nov 7, 2004, at 13:39, Josiah Carlson wrote: > I suppose the question comes down to; should there be a meta framework > for developing servers in Python that specifies a separation between > the > protocol logic and how data gets to that protocol logic? The desire is > for a mechanism to allow people to create a single version of a server > in their favorite framework (SocketServer, asyncore, Twisted, or > other), > and for others to be able to use them in their favorite framework with > little difficulty. That's not really practical. You can't use synchronous protocol code in an asynchronous server without threads or Stackless... so what's the point? As for asynchronous frameworks that are compatible with the Python license, I'm only aware of asyncore (which people generally feel should be deprecated) and Twisted. I think the best course of action would be to create some stripped down derivative of Twisted. A couple changes off the top of my head would make it more suitable for the standard library: - Allow generators to be easily used for asynchrony (much easier to write synchronous-like code in that style, this has been demonstrated by several people) - Throw a blocking API on top because some people will want to use it in a blocking manner (Twisted's testing framework already has this functionality) - Allow more than one reactor per process (necessary to support the previous, because invariably people will use the blocking API from several threads) - Bring in some of the standard protocols (SMTP, HTTP, ...) but not the higher-level versions when available (twisted.web) because those are so much more volatile. -bob
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4