Iain Hanson wrote: [SNIP]
A buffer concept is absolutely essential for TCP. Without it you will run into delays with Nagle, delayed ack and slow start all combine-ing. Yuk!
Streambuf makes sense for the iostream concept. For lower layers the buffer concept needs to be a model of contiguous container. Iterator type can only be guessed at because I don't know what goes on inside the 'C' socket lib or the kernel but first guess would be forward iterator.
Well, if you think about it, the streambuf *is* the lower layer buffer concept (unless you consider ir a buffer over the "kernel buffer"). The methods it offers are simple: get char, put char, and the like. Exposing a "socket" class is a requirement only if the proposed library wants to try to interface with old, "hybrid" code, provide the possibility for some kind of "extension" I really can't think of. A C++-only library could just not have a "socket" class, or consider it "private", and expose as the most basic thing the stream buffer. If you don't need the buffering itself, call pubsetbuf(0, 0). And, as you point out, it's useful to have an "iterator" view of the stream buffer; that's provided by std::streambuf_iterator. Together with Spirit (and an iterator adaptor to turn std::streambuf_iterator into a ForwardIterator), an interesting kind of protocol message parser and object model can be achieved, one in which you have protocol_message classes whose parser function is operator>>. I have an example irc_message class around here somewhere; I'll post it to the list (or put it somewhere) if someone's interested in this. -- Pedro Lamarão