Re: [boost] [Ann] socketstream library 0.7

From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2005-06-12 01:29:29

pedro.lamarao_at_[hidden] wrote:

> Most Internet protocols I've worked with or seen, such as HTTP or the
> Jabber protocol, or mail messages extended with MIME, contain text
> encoded in some charater set indicated in a header field. Try reading my
> UTF-8 mail with your locale set to ISO8859-1 (or some Windows variation).

While most modern protocols support diverse character sets, this does
not generally apply to the encoding of the protocol's primatives.  These
tend to be defined in terms of fixed numerical values that correspond to
ASCII.

As a simple example, >> cannot distinguish between different forms of
whitespace.   As near as I can tell, your best bet for line-ending
sensitive code is to read each line into an ostringstream buffer.  I
suspect that in real practice implementations aiming for high quality
parsing behavior for standard internet protocols won't even try to use
the formatting facilities of iostreams, as they offer almost no value in
the overall scheme of building a parser.

<< and >> are great for things related to human-readable formatting,
where a human's eyes are the primary discriminator, but I am unconvinced
they are useful for reading and writing text to be manipulated by
machines.  I do not think << and >> are even workable, in the general
case, for a protocol who's whitespace and formatting rules do not
exactly match those of C and C++.

>>Besides this, iostreams has many annoying characteristics that are
>>unacceptable for use in many robust sockets situations, such as reading
>>an indeterminant amount of characters, and then just throwing them away
>>if something goes wrong.
> 
> I don't understand what you mean here.

When implementing the >> operator for a custom class, how do you handle
the case where you need to read two primative types, but the second read
fails, leaving the operator holding on to data that it has no way of
'putting back'?  As near as I can tell, this ends up leaving the stream
in a consistant but indeterminant state; something that might be OK for
files, but is entirely not OK for a medium that is not rewindable, such
as sockets.

An improved streambuf could help cope with this, but this is tangental
to the unsuitability of iostreams.

>>In other words, I'd suggest we forget about iostreams.  Design a good
>>socket based on past experience that handles diverse networking
>>situations elegantly, and let some other library like Boost.Iostreams
>>map that to a streambuf, should <iostream> support be needed.
> 
> 
> I sincerely have no idea what is the trouble everyone has with
> iostreams. It's just a formatting layer over a buffer layer.

I think it needs to be demonstrated, in real code, that it is easier to
write a conformant and high quality parser for an ASCII-based standard
internet protocol using the iostreams primatives, than without.  For the
reasons above, I think they will tend to only make things more difficult.

> Every "socket library" or socket application without such library
> support has reinvented a buffer layer; and none of them have considered
> the usefulness of a formatting layer, leaving "sends" and "receives" as
> high up as main().

I am not saying, "<iostream> is never useful for sockets."  I am only
saying that it is not a good primative for general work, done in real
programs with real protocols, and hence is somewhat tangental to the
path of seeking a general purpose sockets library.

With the Boost Iostreams library, it is extremely easy to form a
streambuf from any particular data source.  With this, I completely
disagree with your former statement, and I'd say: An implementation of a
socket streambuf for iostreams is the only thing that a socket library
*doesn't* need to provide.

By the way, take this in no way as criticism of your library, which I
have not formed an opinion on yet.  I am only stating my belief that
iostream implementations are tangental to the primary work of creating a
Boost socket stream library.

Aaron W. LaFramboise