Re: [boost] singleton asio::demuxer as default? (was:asioformalreview begins)

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-27 20:21:39

--- Beman Dawes <bdawes_at_[hidden]> wrote:
> 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.

I like it, except for the following statement:

> > - An io_service object is an extensible collection of I/O
> > services (drivers?).

Perhaps io_services would be better?

To continue the high-latency brainstorming...

Following on from Peter's suggestion of driver, and in light of
io_services vs io_service, what about io_kernel, which is a
collection of drivers? Might sound too low level though.

Regarding Arkadiy's suggestion, I'm not sure about just
dispatcher, although maybe io_dispatcher is ok. But I don't
think it conveys the collection of services idea sufficiently --
unless it refers to a dispatcher from the
Client-Dispatcher-Server pattern :)

I did some reading up on patterns during the break; mostly
Pattern Oriented Software Architecture volume 1. The one pattern
that stands out is the Broker pattern, even though it is
intended for distributed applications. I believe that asio
implements a variant of this pattern. The relevant parts
include:

- A Client (the application) sends requests through a
  Client-side Proxy (e.g. stream_socket).

- A Client-side Proxy encapsulates functionality and mediates
  between the Client and the Broker.

- A Broker registers and locates Servers (get_service()) and
  runs an event loop (run()). It provides a way for the results
  of operations to be forwarded back to Clients (e.g. dispatch()
  and post()).

- A Server implements services, and is registered with a Broker.
  Some Servers are implemented locally to the client (e.g.
  locking_dispatcher_service) and others can be located on a
  remote Broker. In this case you could consider that the remote
  Broker is a virtual Broker that exists within the operating
  system.

So what about io_broker? For people who have used CORBA, similar
rules apply in respect of calling run():

- No need to call run() in a client making synchronous calls.

- Need to call run() if using asynchronous method invocation so
  that results can be delivered.

A possible disadvantage of io_broker is that the name conveys
too much meaning, in that users may feel it is a concept they
need to understand before using the facilities it provides. I
don't think a name like io_services suffers from this.

Cheers,
Chris