[Web-SIG] FYI: nbhttp

[Mark Nottingham]

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 <mnot at 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/