Roland <roland.schwarz@chello.at> writes:
(Sean Kelly <sean@ffwd.cx>) 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 platforms). 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 support. -- Jeremy Maitin-Shepard