TO-DO List for Ceylan-0.3

Thematically organized

• abstract filesystem service (ex : PhysicsFS)
• Singleton : should be templated, if possible
• check that its destructor is actually called on program exit
• all good practises from http://www.owlnet.rice.edu/~comp320/2002/notes/ should be used
• think to a generic plug-in architecture with Module services.
• a whole Object-based hierarchy, like Java, should be made.
• recursive object list should be used.
• a shared library should be made together with the static one, and a way of inspecting their contents should be provided.
• an XML-based extended configuration file reader would be very useful
• interfaces and implementation of the MVC (Model-View-Control) pattern
• Mutex holder used as automatic variable to ensure mutex is released whatever happens
• portable getChar should be made for the classical one (DOS) and its UNIX port in Utils.h
• use a C++ unit test library such as CPPunit
• module architecture should be useful as a mother class for every project module federating services
• add a header in header files such as :

  /* * The Ceylan library. * Copyright (C) 2003 "the OSDL team" (see AUTHORS file) * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or (at * your option) any later version. * * This program is distributed in the hope that it will be useful, but * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * General Public License for more details. */

• add a way of disabling log statements and make them truly costless : a python script which automatically comments them / remove comments ?
• add LogNull, black hole for Logs such as /dev/null
• allow to interface Log System with log4cpp
• add support for dynamically-created channels with channel API creation
• allow to use a webserver as one of the outputs of the Log System, something like LogHTML
• support fine settings for level of detail, and allow to assume default vallues like a state machine
• try to figure out how a log channel could inherit from ostream, in order to be able to use the very useful operator << for log messages
• support dynamically chosen Log systems implementation, like plug-ins.
• default log channels might be among debug, trace, info, warn, error, fatal
• log output might be defined by a configuration file
• channel groups might be useful
• channels might be sorted in a forest (a set of tree) with special commands allowing to change their relationships
• some log channels might be dedicated to efficiency measurement targeted at profiling
• provide a way of defining level of detail relatively to another channel's one (+1, -2, etc.)

• add pkg-config support

Please react !

If you have information more detailed or more recent than those presented in this document, if you noticed errors, neglects or points insufficiently discussed, drop us a line!