alternative roadmap proposal

Hello,

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.

In my eyes CFG is a important joining piece that is needet to bring unix 
systems and higher level interfaces (GUIs protocolls etc.) together in a 
consistent way.

So one point is to make it scale easily and modular from small to large and 
not include too much too fast.

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.

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).

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.

For a little more sofisticated distribution setup different sets of config 
files stored localy on the configuration server could be included into CFGs 
representation classes. For now lets assume they are edited with CFG on the 
sever.

On the cliens a CFG utility periodically (or upon startup and change 
notification) fetches the XML representations "clients" class (included files 
get transfered from the server in the same way as in the first case) and 
merges changes into the "local computer" representation class.


Best Regards,
Christian





-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn