On Wed, 2008-07-30 at 11:21 +0100, Christine Caulfield wrote: > 2. external config modules are rather strange. If I include > <corosync/engine/config.h> (as I'm maybe not supposed to) then then > .readconfig routine gets called with an objdb* rather than a > corosync_api_v1* which the rest of the coroapi routines use. I can > probably cope with this but it looks a bit odd and given what I was > told > on IRC I might not be supposed to be using config.h anyway. > > I appreciate that config modules should probably access the objdb > directly, so I suppose my question is "am I supposed to include > config.h" in an externally built module ? > > Chrissie
Ok I have studied this in detail. The root of the problem as I see it is that the objdb has an api call object_write_config. This API belongs somewhere else, probably directly in the coroapi but definitely not in the objdb api at all. There are a few problems with the current api location: 1) It disallows the passing of coroapi to config.h functions 2) objdb.c now has a dependency on main.c from the implementation of object_write_config Here is what I suggest: We put object_write_config in main.c. config.h then takes a coroapi. The way I had envisioned all of this is that objdb contains the core code for accessing and configuring an object database. Some other file contains logic for writing the current objdb contents to a file using the user specified config interface function. This provides a tidy abstraction for all the pieces. I don't want an association between the runtime parsers and objdb in the interface of objdb. I will write a patch and we can take a look and see how it fits in with fabbione's work. _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
