From: Jeremy Maitin-Shepard (jbms_at_[hidden])
Date: 2004-01-29 03:56:07
Roland <roland.schwarz_at_[hidden]> writes:
> (Sean Kelly <sean_at_[hidden]>) wrote:
>> What remains an issue in my mind is how far to take this. Socket and
>> file classes for each platform at least... what else?
The obvious thing to support is win32 named pipes (in addition to
various types of sockets, including unix domain sockets on unix
One unrelated issue that occurs to me is elegant handling of
out-of-band data on various types of sockets (particularly TCP).
> TTY, USB, FireWire, Parallel, .....?
> Since file classes normaly also imply all other types of communication
> resources this should be enough I think. But then different methods of
> opening and parametizing need to be abstracted as well. Perhaps
> by an ioctl method or similar? Or what about a library/framework where
> the user optionally can plug in the system dependent low level part while
> providing some implementation for the usual resources. This could be
> done like the filebuffer concept in streams?
It might be possible for the library to allow user extension, provided
that the user extension uses, on UNIX platforms, a file descriptor that
can be polled using the various polling methods employed by the library,
or on Windows platforms, a Windows HANDLE that can be used with
asynchronous completion ports. Having this level of platform dependence
in this extension interface seems somewhat undesirable, however. On the
other hand, it is very useful to be able to support things like tty's
and pipe(2) pipes that would otherwise be effectively impossible to
-- Jeremy Maitin-Shepard
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk