The biggest functional difference (there are cosmetic ones that could
be papered over) is that there needs to be some way to pause bytes
being pushed out; this was discussed a LONG time ago here WRT async
servers (I haven't followed discussion closely since, so apologies if
I've missed something more recent).
The other difference is that WSGI isn't symmetric regarding requests
and responses; you push a response out with a function, but you have
to read request bytes in from a file-like object. This doesn't work so
well when you want to invert the API to use it as a client API as
well, and it doesn't work with the all push-based approach that
push_tcp takes (i.e., the socket pushes the app bytes upon a read(),
and the app pushes bytes to the socket with write()).
I should have mentioned -- the easiest way to see the API is to look
at at the bottoms of src/client.py and src/server.py, as well as
scripts/proxy.py.
Cheers,
On 17/06/2009, at 9:49 AM, Graham Dumpleton wrote:
2009/6/17 Mark Nottingham <m...@mnot.net>:
I've recently put up a library that I've been working on for a
little while,
nbhttp:
<http://github.com/mnot/nbhttp/tree/master>
"nb" stands for non-blocking; this is explicitly an
asynchronous/event-driven library, with both a server and a client
component. They can be trivially used together to implement a proxy.
The aim is to be HTTP/1.1 compliant (and it's most of the way
there, with
the exceptions of expect/continue and pipelining support), to be as
performant as possible, and to expose as much of the raw protocol as
possible.
That last motiviation is because nbhttp is used by REDbot
<http://redbot.org/>, a HTTP resource checker, and it needs "deep"
access
into what's happening on the wire (without intervening software
trying to be
helpful).
It is very rough, mostly undocumented, and will probably crash. It is
WSGI-like, but not WSGI compatible, because there were a few places
where
WSGI was too constraining. However, it may be useful as food for
thought in
API revisions. Or not. :)
Can you explain the difference to WSGI so that don't have to go
digging through source code to work it out, or is there documentation
somewhere which explains it?
Graham
--
Mark Nottingham http://www.mnot.net/
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com