Re: [Config4gnu-developer] Re: alternative roadmap proposal

[C. G. <c.g...@tu...>]

Thank you for explaining some of the issues involved, Justin.

> > What was the reasoning to slide WBEM right into the heart of CFG? ;-)
>
> I think there were 2 main reasons for putting it right in.  First, we don't
> want to depend on Xerces anymore.  Second, if we used another XML library,
> then we'd essentially be generating XML in our bottom/middle layer,
> converting it to WBEM/CIM, which in turn would convert it to XML for remote
> communication

I thought CIM over XML is only optional and not necessarily needed on this 
level. (Only beneficial for WBEM clients.) Installers, package managers, 
scipts etc. have a need for comand line config tools and serialized config 
data. They should not even need to use a full blown xml library to make use 
of CFG, and I don't think local command line tools would like to depend on 
any remote configuration protocol.


> we'd really only need to do the XML -> WBEM/CIM
> conversion which might not be too hard.

Yes, expecially compared to the many config file -> WBEM/CIM conversions that 
when hooking WBEM directly into the parsers. Parsing CFGs xml doesn't seem to 
be that much of a difference from parsing a config file. Just that it 
literally parses all cfg supported config files.

> Also, we didn't want to have the
> C++ <-> perl communication as only very recent gcc compilers don't have a
> bug that causes issues w/ it.

Ok, hopfully recent gcc versions will become mainstream quickly. As the main 
constrain for CFG at the moment seems to be the time available for it, it 
will probably have to stay for a while like it is.

I'd find it really unfortunate though, if the original intention to improve 
the "nightmare" of Linux/Unix configuration would be buried in the meantime.

Kind Regards
Christian


Jason: Maybe cfengine might also be interesting four you if you have to 
administer a bunch of boxes. (not knowing anything about your setup though)