In addition to the DB
imposed changes and the planned new features, RATS V2 will also include
a series of optimizations. The current experience with RATS V1 has led
us to believe that three major classes of optimization are required.
Configuration files
The current configuration
files are fairly complex, and while this complexity brings great flexibility,
it also increases the slope
of the learning curve to a near fractal shape. We have received
comments and suggestions on both sides of the issue. A number of
system administrators welcomed the current flexibility while other
have either expressed puzzlement or at least some level of difficulty configuring
RATS for a simple system. RATS V2 will maintain the same level of
flexibility but it will further divide the configurations files into a
few smaller ones. The various options will be redistributed in such a manner
that the fewer but more likely to be used options will be contained in
one file, while the rest and less likely to be changed options will be
contained in a different file.
This kind of division already exists
(rats.conf and rats_internal.conf) but the granularity does not seem to
be sufficient. RATS V2 will have at least three configurations files
or even as many as four or five.
Client Libraries
Currently both the client
daemon and the client tools share a common library. However there are distinct
set of functions in common library (RatsLib.pm) which are only used by
daemon or the tools but not both. This creates the unfortunate side
effect that both the daemon and the tools have a larger memory foot print
then strictly necessary. To solve this problem the current library will
be split into three parts, RatsCommon.pm containing functions common to
all applications, RatsDaemon.pm containing the functions specific to the
ratsd daemon, and RatsTools.pm containing those functions specific to the
end tools. The actual function to library membership remains to be
determined by a careful analysis of the current and planned tools.
Algorithms
Some of the current algorithms
employed by RATS for various functions may not be optimal. The prohibitively
short development time allocated to RATS V1, did not allow for proper analysis
of all the algorithms involved. Some of these algorithms will be fully
replaced and re-implemented with the addition of the client DB, however
the continuing support for the flat file mode dictates that the same algorithms
must be optimized for both modes of operation. For example the UID generation
method is currently non optimal and while greatly simplified in the DB
operation mode, a proper substitute must be employed for the flat file
mode as well. Another set of algorithms will not be impacted by the addition
of client DB, but will still require careful analysis. The prime example
of this, is the whole process followed by rats.cgi for creating accounts.
The stateless nature of the Web based applications adds a new level of
complexity and the current implementation, while functional, is quite tangled
and hard
to debug.