#3 Listener reimplementation

[Chris P. Ross]

Geoff has described wanting to reimplement the way connections are set up to listen for incoming connections. Geoff, you should describe that intent here, and then we should work towards coding it. Or should it be delayed?

[Geoff Adams]

Logged In: YES
user_id=1171411
Originator: NO

I have documented this new design in the object-design.rtf file in the source tree. Here is a summary:

Create a new Connector class hierarchy. Objects in this class hierarchy will contain:
- Type of connection (TCP socket, UDS socket, file, memory handle)
- Path, address, or other specifier to connect to
The top-level Connector class will be abstract, and declare (but not implement) the following behavior:
- listen for connections of this type (if appropriate)
- establish outgoing connections of this type
- read from and write to the underlying connection
- disconnect from the underlying connection
- handle disconnection events from the other side.

With the introduction of this new hierarchy, we will still need only one Listener class, and we will need only the Connection/Outlet/BiDirConn class hierarchy for Connections, with no connection-type-specific classes under Connection. Nor would there need to be a ConnEventHandler anymore, so this should result in approximately no net change in the number of classes.

So, to listen on, say, a socket, you create a Connector object containing the appropriate information, and instantiate a new Listener, passing the Connector to its constructor. When a connection comes in, Listener accepts the connection (probably by calling an accept method on Connector) and instantiates a new Connection object, passing it the Connector it already has.

To establish a new, outgoing connection, you create a Connector object containing the appropriate information, and pass it to the Connection constructor to instantiate a new Connection.