In order to minimize the impact of RATS V2, rather
than customize everything to work with RATS's interface to the client side
DB, the DB will be integrated into the UNIX system as much as is possible
with "glue" that is well understood by UNIX tools in general. In this iteration
of RATS, the glue will be the standard UNIX flat files. The flat files
will be used to initially populate the database, and they will be the means
by which a lot of system components gain access to the data stored in the
DB. Although this might seem self defeating at first, it isn't. The DB
will periodically dump its contents into the standard flat files (probably
at user definable intervals). Since they will not have an altered format,
anything that simply reads these files should be unaffected by the data
being stored in the DB. However, these files will never be fed back into
the DB after the initial load except under catastrophic failure conditions.
Since these files are really write-only as far as the DB is concerned,
anything that writes to these files will need to be replaced or altered
to understand how to speak to the client side DB. As far as the flat
files are concerned data will be pushed from the back end to the front
end. At first this seems to go against the grain of the general design
of RATS V1. Server pushes do indeed go against the RATS model, and that
model will not change. The part of the RATS model that is changing is that
lots of small real time updates are being redirected to something better
suited to deal with them (the DB), and all those small updates are then
replaced with one big scheduled update at periodic intervals as far as
the system is concerned (which is something it can deal with better). Rather
than add a server push of data, what we are really building is an accumulation
buffer for lots of little client pushes, and making it look like one big
client push. Although this solution isn't completely transparent as most
would like, it should be feasible to implement. It could also be used in
the future to feed ypmaps or LDAP with some work. In addition, if the industry
standardizes
on a better method for account management than the standard UNIX flat
files, the flexible generic abstraction of data provided by a real database
should ease the transition to this new method. The current design is only
as compatible with LDAP as much as the standard unix flat files are. LDAP support
can be implimented in the future in a more robust manner if it is needed.
As LDAP appears largely to present data about a person that is beyond the
scope of any one subsection of RATS, it is probably outside rats to present
this data. This statement however is far from final as LDAP's role at the
university is at best ill defined currently. Should we determine the proper
use and scope for LDAP at the university, I am sure RATS role and functionality
can be altered in kind.