Really good work! Also make sure this CONFDB ID doesn't collide with CMAN's service id.
We had also spoke in the mailing list and IRC about having the ability to load a configuration parser for a specific service (such as cman +corosync parameters) + the objdb library into one binary. This binary would then not be required to access the aisexec if, for example, it wasn't available (during initialization). I am really sold this is a great idea after having thought about it in greater detail. For future enhancement ideas, I think we should consider the following: 1) make the API load the objdb object and use that locally instead if the configuration parser is set in the environment variable. this can be done by linking objdb.lcrso into the binary via the lcr_ifact_reference API if the environment variable is set for the config parser. 2) make the configuration parser a more general "configuration plugin" so that it is not only responsible for reading the config file, but also writing it. These two ideas would allow us to use the objdb with aisexec loaded or without and to store the proper state of the objdb into a configuration file. Looks good for commit to trunk. Regards -steve On Tue, 2008-04-15 at 14:51 +0100, Christine Caulfield wrote: > This patch provides a 'confdb' subsystem which allows external users > access to the aisexec objdb. > > A couple of things to note: > > 1. I have added some *_iter_from() calls into objdb for use by the > library, this allows the library to keep its own context without > bothering the objdb internals or even the lcrso. The existing aisexec > clients of objdb don't use these, they use the old *iter and object_find > calls that hold their context in the objdb itself. It might be worth > retiring the old calls in favour of the new ones and making the clients > keep their own context. This would probably involve memory allocations > though... > > 2. The library currently only keeps one iter/find context per user. This > means that you can't write a version of objdb_dump() using the library > ... YET. Because the library keeps its own context this could be added > without disturbing aisexec. The API allows for it. > > _______________________________________________ > Openais mailing list > [email protected] > https://lists.linux-foundation.org/mailman/listinfo/openais _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
