On Fri, 23 Aug 2002, David Nolan wrote:
> We've created a representation of the MON configuration data in a database > format, but kept the design flexible enough to allow it to be extended > easily to adapt to future MON changes. (And hopefully to allow the > database design to be used to store the configuration of systems other > then MON) This sounds very similar to what I'm trying to do. > We then dump the contents of the database into a flat XML representation, > and use XSL stylesheets to translate the data into a mon.cfg file. But if you have the configuration in the database, why not hack the mon scheduler to read the config directly from the database instead of dumping the database, recreating the mon config file, and telling mon to go and re-parse it? This would be much more efficient, though it would require hacking the scheduler. I think this is where modularizing the mon data structure and storing it with some sort of (hopefully transparent) object persistence mechanism would be a a big win, though it would require hacking the scheduler. This could give us database independence (via DBI; even CSV text files would be supported as a back end, so no need to install an RDBMS for small installations), and a consistent API to the configuration data that could be used by the mon scheduler and any configuration program. We could keep using the mon.cfg file as a configuration mechanism by taking out the parser code from the scheduler and parsing the file into objects instead of a monolithic data structure. But whatever-- if you have something that works, that's great. Dan -- Dan Urist [EMAIL PROTECTED] http://www.world.std.com/~durist
