Todo List

Class CircBuffer< _Tp >: XXX - perhaps not technically a "circular buffer". Maybe rename?

Class ConfigException: This should be moved to be a subclass of CMException.

Class ConfigFactory: Filename decisions need to be made. What file name patterns should apply to each of the [currently three] formats of configuration file? Only YAML has a documented file naming convention...

Class Connection: Should Connection have initiate_connection() and/or shutdown() methods? Currently the thinking is "No", but it may need them if we move to a design other than "connected at construction" and "disconnect [only] at destruction".

Member ConnEventHandler::operator() (Connection *): listener_thread currently received Connector*'s, and it should probably be responsible for making Connection's out of them.

Member Getcap::load_entry (const string &): We should probabaly convert this code in Getcap::load_entry() to use the vector<> Config::config_keys.

Member Getcap::load_entry (const string &): Perhaps the Getcap code should recognize both the 'local_socket' name, as well as the older 'sf' (socket file) name/key.

Member MasterController::start_connections (): MasterController::start_connections() doesn't know how to tell if it should be connecting to a TTY or a TCP connection!

Member MasterController::start_connections (): We need to write the code that will allow a server to listen on a TCP address/port, as well as the ability to listen on a UDS.

Member MasterController::start_connections (): We need to move the setup of the Listener (and therefore the Incoming) up, so that we don't construct (and therefore connect) the LogFile and/or History objects if we're just going to exit...

Member MasterController::wait_for_signal (): Consider rethinking the SIGNO definition, here. Do we need to do this with a define? Could we use a pointer?

Member MasterController::~MasterController (): Should send messages or signals to our recipients.

Member Messageable::~Messageable (): I need to figure out a way that I can ensure, upon destruction of a Messageable, that noone will ever try to send messages to us. They could still have a pointer to us, and that would be bad.

Member Messageable::handle_message (MessageP &): Need to modify this function to operate the way we expect it to. Will it get data? Where does it need to send it? Since we're not in Outlet anymore, we can't just assume it's for us.

Member Messager::recipients: The list of recipients in Messager is currently a std::list of Messageable*'s. This is atypical of the way we're handling this sort of thing now, where we're generally trying to use Loki::SmartPtr rather than standard unreferenced pointers. Is it safe to just treat all such Messageable objects as MessageableP's, and then we can dynamic_cast the contained pointer when needed to determine if it's an Outlet, or the like? This will work, becasue Messageable is a super-class of Connection, but is it the right thing to do?

Member SocketConnector::connect (): SocketConnector::connect should be able to call bind() so connections can be initiated from a specific address, if/when desired.

Member SocketListener::disconnect (): Should this method be exposed? Or should we just expect the owner to delete us, which, btw, also calls disconnect()?

Member SocketListener::make_incoming_socket (void): The fact that we lock a mutex here suggests that we want to make a new incoming socket only if we're not already in the process of doing that. So, check first. Note, however, that we're contending for an external resource; opening a socket at the given SocketAddress. We need to be mindful that we could be in a race with some other process for that resource, and handle failure (presumably in bind()) accordingly. We need to think about how a mutex can help us here.

File cmconfig.h: ConfigException should be moved to be sub-classed from CMException