Boost logo

Boost :

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2006-04-10 09:49:45


Hello all,

One request that came out of the asio review was that some sort
of iostreams support, similar to the existing iostreams example
included with asio, should become part of the library's public
interface.

I'd like to start some discussion on what form iostreams support
should take in asio. Here are my ideas so far, which only really
cover the highest level.

The goals of iostreams support are to:

  - Support simple use cases. (Does this include servers?)

  - Abstract away complexities like io_service (aka demuxer),
    host resolution, etc.

In asio's CVS post-review I have changed the socket types to be
"strongly typed", e.g.:

  ip::tcp::socket
  ip::udp::socket
  ipv4::tcp::socket
  etc..

Following this pattern, for protocols that are stream based
(like tcp) I plan to include typedefs for iostream objects,
e.g.:

  ip::tcp::iostream

For a client-side connection, this could be used as follows:

  ip::tcp::iostream s("somehost.com", "http");

This would automatically resolve the host and service names, and
take care of managing IPv4 or IPv6 protocol independence for you
(i.e. it will try all endpoints returned by resolving the
host/service until it gets one that works).

What lies between this high level interface and the current asio
interface? Exactly how much of it is exposed as part of the
public interface?

I know Jeff Garland has some ideas about integration with
streambufs, so I'll let him expand on them. Others please do
feel free to jump in. The internals of iostreams is not an area
I am familiar with.

Cheers,
Chris


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk