A while back I drew this diagram to show what we were aiming to design, in broad terms, for the next generation aisexec/cman config system:
http://people.redhat.com/teigland/cman3.jpg I think perhaps that diagram attempts to do too much, and I've drawn another: http://people.redhat.com/teigland/cman3b.jpg The big problem I see with the first diagram is that it tries to use objdb to solve the meta-configuration problem [1]. That's a hard problem, I'm not sure objdb is the right place to solve it, I don't think we have enough information to solve it properly right now, and I don't see that we have a pressing need to solve it right now. So, the second diagram steps back to what Fabio has already implemented, more or less. Lon pointed out another problem with the first diagram, and that's that we want to be able to read config values without openais running, and running properly. That's one of the things we were trying to get away from with ccsd. [1] Just to be clear, the meta-configuration idea is where a variety of config files can be used to populate a central config-file-agnostic respository. A single interface is used by all to read config data from the repository. Even if we did this, I don't see what it would give us anything. All our existing applications access data that's only specified in a single config file anyway, so interchangable back-end files would be an unused feature. _______________________________________________ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais
