Re: Planning meeting results

Hi,

I'd like to add my two cents sice I was impressed so much about the concepts 
in CFG so far.

> [We] are concerned  with some of the problems that the current
> code has. These include problems with  dependencies, and architectural
> difficulties with passing XML back and forth.

I recognize the issues but somehow I don't think the pictured way is the 
apropriate solution. IMHO introducing WBEM, CIMOM and CIM over XML will first 
of all bring more dependencies and as you described additionally seems to be 
also a fairly limited protocoll for us to build on. Many additions itroducing 
complexity all over the place seem to be needed.

The fact that it might be an established standard with existing clients that 
can conect might be tempting, but FWIW I think a CFG "top layer interface" as 
mentioned here before that provides WBEM is better suited for that than 
running CFG entirly over WBEM. What about next year when the next config 
protocoll comes around?

Concerning the benefits of an extra configuration protocol.
Does remote access to CFG need to require more than a ssh connection? Is 
another open port really always neccessary?

I am not convinced. I thought that it is the beauty of the unix-way to 
practically combine and use existing facilities. Same for access rights to 
the configuration data, they are already handled by the filesystem.


When thinking of remote administration of computers simply accassing 
individual machines doesn't cut it, I think. 
That is one thing why I was so positive about CFG with its middlelayer before, 
assuring a common consistent representation to all frontends.


Configuration entities where put into a hierarchie of different classes.
At this point only "computer" existed but I alread pictured to devfine classes 
like "servers" or "workstations" that could be configured in one swoop. 
Propagating of the files (push/pull ?) possibly done by some other system 
like FAI or cfengine or plain mounting of remote filesystems. Or a cfg 
"remote machine parser" could open a ssh connection and fetch/writeback 
files. (All run with user privileges with the option to "su")


Without the middlelayer CFG is not that much different than other tools like 
libconf. The distribution independence relies heavily on this common 
abstracion layer where all systems look alike. And I guess it is much harder 
to convince people that having their frontend depend on WBEM + cfg 
enhancements, CIM (over XML), and a cfg-client lib is just as nice.



So to summarize, I think we coould be able to figure out a even more universal 
way to reduce dependencies and to tackle the problems, including providing 
WBEM support but without putting to much restraint on cfg's future in the 
"unix-way".


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