Re: [Config4gnu-developer] alternative roadmap proposal

[Justin Y. <ju...@sk...>]

On Mon, 9 Feb 2004 14:34:45 +0100
"C. Gatzemeier" <c.g...@tu...> wrote:

> I understand that since I was not so conviced about the proposed
> changes I need to try to show an alternative. So here I'll try.

I really appreciate your feedback, I'll admit that I'm not completely convinced that WBEM is the best technological/design-based direction, but I'm fairly convinced that it is the best overall decision for the CFG project.  I'm all for whatever will help CFG the most, which may or may not be what Jason and I initially decide on.
 
> I like the schematic given at
> http://config4gnu.sourceforge.net/docs/schematic.html
> Maybe just the authentication, remote administration, and
> backup/restore needs to be moved one layer up to avoid unnecessary
> difficulties.

This is also a sticking point for me.  The main advantages that WBEM/CIM gives us are remote administration and a sort-of abstract configuration editing system to build upon.  Is the CIM spec more limiting than our XML data model, yes, absolutely.  Will it always be, I hope not. 
 
> The middlelayer provides a common representation in XML with addiional
> 
> features and logic.
> This is CFGs main thing, providing a good and unified abstraction of
> the configuration. Everything else gets much easier when build on
> that. It's ok to hand XML back an forth as long as it is going to be
> used localy, it is just analogous to opening the config files
> directly.
> 
> Alternative interfaces can be build on that CFG representation and
> constitute new parts of the "CFG top layer" WBEM and LDAP seem to be
> of particular interest here. On the other hand a CFG bottom layer LDAP
> parser would also be very interesting for systems that have part of
> their config stored in LDAP directories.
> 
> For the XML representation there should never  be a need to make it
> accessible from remote from within CFGs middle layer. As the name says
> it is just a representation of the config files with the same access
> restrictions (bound to the user calling CFG).

This is very true.  From a design perspective, I think the major negative on this is that we'd have to maintain *2* copies of meta-data.  One for WBEM/CIM and one for our XML system.  If we could create a near-flawless translation layer, then this is a moot point.  I think examining how possible that is would be a worthwhile experiment.

> For remote adminstration I picture remote config files could be
> included into the CFG representation with a "include" in the
> config4gnu.xml meta-definition that points to them. CFG could open a 
> ssh connection to that machine and remote config files and
> meta-definitions can be parsed.
> 
> This first case wouldn't even require CFG being installed on remote
> machines and would be a simple direct interactive operation.

Agreed, this would be possible, and potentially easier to use.  However, WBEM may soon be as commonly installed on a server as SSH is today.  WBEM potentially gives us more advanced features over SSH, with little effort on our part.  I think this really is the crux of the matter, the amount of work.


Successfully using WBEM really depends on 2 assumptions.  The first is that any features WBEM is severely lacking will be added in the near future.  The second is that WBEM will soon be widely-used.  

Will this happen?  Its hard to say.  From my limited exposure to it, WBEM seems to be a reasonable cut at a first version of a protocol.  It definitely should have more features.  Ironically, it seems WBEM would be more useful if it were more like XML (hierarchical and more extensible).

Either way, CFG does need some architectural reworking, and WBEM seems a convenient component to slide in the middle of our system that we want and need to better separate.  I think the difficulty is integrating WBEM into our system only as much as we need to, in the event that WBEM turns out to not be the best approach.

If we had unlimited programmers working on CFG, I think closely integrating WBEM into our system (as opposed to providing a WBEM API, in addition to our normal API) would not be as good of an idea.  I'd really like to hear any suggestions on how to change that proposed diagram of our system (in the email Jason posted to the list) so that we can avoid writing code that does exactly what WBEM does and be able to maintain our internal XML architecture.

Justin


-- 
SkiingYAC
Custom Solutions
http://www.SkiingYAC.com