"Christopher Kohlhoff" <chris@kohlhoff.com> wrote in message news:20051221090730.33683.qmail@web32603.mail.mud.yahoo.com...
...
So I wonder if the problem is really just one of naming. Specifically, the name of the demuxer class.
Asio started life as a library intended for asynchronous use-cases, and for developers with that sort of background I believe the name demuxer (i.e. demultiplexer) is perfectly natural.
Now that it has grown into general purpose use, perhaps the name should reflect the expectations of a wider audience.
I think that would be very helpful.
I propose that it could be called something like "io_system". (Other naming suggestions will be appreciated.)
"io_system" seems a little broad. I think of an "io_system" as encompassing all I/O mechanisms an operating system supports. A web search turns up broad phrases like "The basic model of the UNIX I/O system is a sequence of bytes that can be accessed either randomly or sequentially." "io_engine" implies to me something at a very low level, like the set of device drivers. How about "io_service"? That seems both narrowly focused and about the right level to me. I've changed "io_system" to "io_service" in your text below. Reads quite well IMO.
Consider the following statements:
- An io_service object must be initialised before sockets (or other I/O objects) can be used. See the portability requirement above.
- An io_service object is an extensible collection of I/O services (drivers?).
- Synchronous operations implicitly run the io_service object for an individual operation.
- You must run() the io_service object for it to perform asynchronous operations on your behalf.
- You can partition your program by using multiple io_service objects.
--Beman