[boost] Re: (Another) socket streams library

From: pedro.lamarao_at_[hidden]
Date: 2005-04-22 10:06:10

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