RE: [boost] Re: sockets library

From: Darryl Green (green_at_[hidden])
Date: 2001-12-23 20:42:16

> From: bill_kempf [mailto:williamkempf_at_[hidden]]
> Sent: Saturday, 22 December 2001 2:10 AM
> --- In boost_at_y..., Darryl Green <green_at_t...> wrote:
> > <rant>
> > There are LOTS OF platforms in existance that are not win32, un*x 
> or mac and
> > do have BSD socket style networking.
> 
> Yes, and your point is?

My point is that there was much discussion of efficiency, protocols, usage
etc. that were somewhat coloured by (among other things) the platform. My
point was not very well made. Perhaps I should have just said;
"most" in the requirements for a library won't cut it - the library needs to
be designed with the intent of supporting "all" - and I don't mean by making
it a single huge monster.
> 
> > There are environments in which using iostreams is BANNED and where 
> using
> > sockets certainly isn't.
 
> Banned?
Yes.

> Why and which environments?
In the environments in question iostreams have cost a lot in terms of code
size and performance while giving very little back in the way of
functionality. This is partly a library design and partly a library
implementation problem imho - I gather that Dinkumware (and others?) have
managed to address this, but the easy way out was just to avoid the whole
thing. This hasn't caused us much/any pain - though obviously there are
problems when trying to use other libraries that in turn use iostreams...

> Embedded?
Yes.

  The reasons why 
> iostreams are avoided there (I don't like the term banned) probably 
> won't apply to a binary_iostream.
Yes. Agreed.

> 
> > There are protocols that are not designed so humans can read them, 
> but are
> > designed so the data will fit (either a lot of data, or a small 
> pipe) and/or
> > be efficently processed at each end.
> 
> Yes, and that's what a binary_stream will allow you to do.
Good.

> 
> > There are protocols that have some truly exotic and complex internal
> > structure that no amount of iostream handling is going to help 
> with. Well -
> > ok - I guess someone could build some interesting magic for 
> formatting data
> > as (say) ASN.1 via iostreams, but I'm not volunteering.
> 
> This shouldn't be too difficult to do.  I don't believe it will 
> require any "interesting magic", either.
Depends what you want it to do exactly. Do you think it would be simple to
build something that would replace the functionality of SNACC and Agent++
for a start? I've thought about doing this and pragmatism (read deadlines)
has won the day. Maybe I need to think about this some more, but for complex
types I don't see fitting this sort of stuff into an iostreams view of
things being helpful/possible?
> 
> > KISS.
> 
> YES!
> 
> Start with a few basics, such as a socket class and a network_name 
> class.  From this build some higher level abstractions: a socketbuf, 
> socket_stream and binary_socket_stream (first requires a full 
> binary_stream library).  From these (or maybe from the lower level 
> socket class, though you'll lose a lot of very useful functionality 
> if you do this) you build even higher level abstractions along the 
> lines of what Jeremy's suggested.  Build things in layers, keeping 
> each layer as simple as possible.
Yes. Precisely. My only real concern was that there might have been a
restriction on what/how higher level protocols and other abstractions could
be built (efficiently) without getting back down to the level of a trivial
wrapper around the standard sockets api. This could happen if machinery to
support "most" protocols sneaked in at too low a level. You and others have
convinced me that using streambuf is not going to introduce this problem.
Please consider my objections withdrawn.
> 
> Bill Kempf
> 
> 
> Info: http://www.boost.org  Send unsubscribe requests to: 
<mailto:boost-unsubscribe_at_[hidden]> 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/