Spend a few days off line and you suddenly miss a whole conversation :-( It's going to take a while to catch up... Recent IOstreams discussion has indeed been very interesting, espescially as I am finally getting round to implementing buffers and filters for giallo (boost.sockets). At the moment I am leaning towards ACE style message buffer, using the apache filter idea of flush/eos/eoc control (but trying to avoid any knowledge of the underlying resource). So where is giallo today (apart from being temporarily broken on gcc due to mpl changes)? i) Low level, platform header hiding, object based wrappers of sockets, named pipes, select, and completion ports (and a POSIX aio wrapper on linux that I have tried to get to work in many different ways and failed so far). ii) proactor and reactor interfaces, with policy based implementation, provided by bridge classes to the low level completion port and select wrappers above. iii) 'event completion notification' style connector, acceptor and connection classes for sockets and named pipes. These classes combine a demultiplexer with a resource (socket, pipe, etc), and can use a proactor or reactor demultiplexer interchangeably (via template parameter). The connection selects the synchronisation mode (block, non-blocking, asynchronous) of the socket based the demultiplexer. The library is thread aware (can run multithreaded, will create threads if asked to, uses threads to do asynchronous connect if not natively supported, etc) There is a streambuf implementation, but I have not found a way to implement this without it degenerating to a thread per connection model. I feel quite strongly that the decision to implement connection, connector and acceptor concepts with a single (in this case 'event completion' style) notification interface, regardless of the demultiplexer mechanism used, is very important, and can lead to a stream/filter concept that is independent of demultiplexer, of blocking/non-blocking/asynch mode and thus independent of the resource used.