From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-06-09 16:13:48
On 6/9/05, Simon Richter <Simon.Richter_at_[hidden]> wrote:
> Caleb Epstein wrote:
> > Please do! Does either of the implementations offer an interface to
> > the sockets at a lower level than iostreams though?
> Mine doesn't, so far, as I haven't seen a need for it.
I believe it is an absolute requirement for a C++ Sockets library.
> > I personally prefer to use lower-level read/write semantics with
> > sockets and handle would-block conditions etc in my own code.
> This is the main reason why the manager code is not implemented yet: I
> am still trying to think of a portable way to reset the read position if
> an extractor fails due to no more data being available presently.
Well, I don't think it makes sense to implement iostreams on top of a
non-blocking socket interface. If a user wants to use "socketstreams"
they can reasonably be forced to use a blocking I/O model. Although
the Boost.Iostreams library may make non-blocking doable.
This should not preculde a different user or even another part of the
same application from using a non-blocking socket interface at "layer
1". IMHO of course.
Proposed Socket Library Layers:
-- Caleb Epstein caleb dot epstein at gmail dot com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk