[Openais] [PATCH] Use objdb

Steven Dake sdake at redhat.com
Tue Apr 4 12:08:05 PDT 2006


Sorry I was thinking one thing and you were thinking another and we had
a lack of communication (my fault).

There is a big problem with this patch.

aisparser shouldn't be a "service handler" it should be more like a
loadable interface (that may be the entire or part of a component).
This is the same thing that objdb is.

In the current main.c code, the object database is loaded early on:
     * Load the object database interface
    res = lcr_ifact_reference (
        (void **)&objdb,

We want to do the same thing with aisparser.  It would look something
like this early on

	if (env_override) {
		parser_name = env_override_name;
	} else
		parser_name = "aisparser";

	lcr_ifact_reference (

Within the cman component, it would still be possible to easily specify
a parser interface along with a cman service handler interface.

This also allows services_link to occur outside of the bootstrapping of
the service handlers therefore allowing for the previous policy we
discussed wrt default services.  The whole "do it again" thing is just

Sorry for not being more specific previously..

Other then that problem the patch looks good.

I'm not sure what the parser interface should look like.  I guess it
should be similar in nature to the previous interface so that we can get
back some kind of errors from it to display to the user in main.c.

On Tue, 2006-04-04 at 14:38 +0100, Patrick Caulfield wrote:
> Steven Dake wrote:
> > On Mon, 2006-04-03 at 03:59, Patrick Caulfield wrote:
> >> Steven Dake wrote:
> >>> Patrick
> >>>
> >>> Good work exactly what I had in mind.
> >>>
> >>> Few comments which I'd like resolved before commit
> >>>
> >>> I really dislike the name "conffile" could we use "aisparser" instead?
> >> no problem.
> >>
> > 
> > cool
> > 
> >>> There seem to be a lot of
> >>> -
> >>> +
> >>> What are these in the patch for?
> > 
> > ok this is fine I am not opposed to cleaning up the code wherever there
> > are problems :)
> It's more an affectation than a problem to be honest! I have a "remove
> trailing space" macro and I use it almost as a reflex action.
> >> They are where my emacs macro has removed trailing spaces at the end of a
> >> line. I'll try to tidy them up...but I /hate/ trailing spaces :)
> >>
> >>> If any "service" parameter is specified, none of the default services
> >>> will link with your changes.  What I would prefer is that all default
> >>> services link in all cases, and if the user wants a newer version of a
> >>> default service, they can specify the service tags in their
> >>> configuration file and it will overwrite the key/value pair.
> >>>
> >>> In the case the default configuration parser is overridden, I would also
> >>> like the default services to link.
> >>>
> >>
> >> I was trying to get a system where the user could remove service that were not
> >> needed. How about a "defaultservices: " option which defaults to "yes"? that
> >> way the user could override the default service list if necessary or simply
> >> update versions if that's what is wanted ?
> > 
> > This works for me.  As long as the user wants to turn off default
> > services, they should be able to.  From a support standpoint, I don't
> > want services disabled by default though, because it might make for some
> > confusion when trying to configure openais.
> That sounds fair.
> New patch attached.

More information about the Openais mailing list