Planning meeting results

Justin and I finally had a sort of planning meeting to discuss our
intentions with  Config4GNU. Both of us are still interested in working on
the project, but 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, of course, being interested in WBEM, advocated looking further into
using WBEM as a  client/server communication protocol and even using WBEM's
object model (called CIM) to  express configuration data. This approach is
going to have both advantages and  disadvantages. Advantages include being
able to leverage existing WBEM management  clients, not having to develop
our own client/server protocols and authentication  mechanisms, and
simplifying the code. The disadvantage is that CIM's object model is not 
hierarchical, which makes a lot of our XML-based object code useless with
CIM.

Here are some of the results of our discussion:

1. We decided to pursue the WBEM direction.

2. A WBEM architecture would look something like this:
(Please view in a monospace font for this to look correctly.)

+-----------------------+        CFG will provide 1 or more clients
|        Clients        |   <--- driven by client meta-data
+-----------------------+
|  CFG Client Library   |   <--- shared code that uses CFG-specific 
+-----------------------+        client meta-data to enhance clients
|     WBEM library      | ---------
+-----------------------+         |
  |                               |
  +--CIM over XML protocol--+     |
                            |     |- Existing code (OpenWBEM,
      +-----------------------+   |  OpenPegasus, etc.)
      |         CIMOM         |   |
      +-----------------------+   |
      |   Perl Provider IFC   | ---
      +-----------------------+
      | Perl Provider Scripts | 
      +-----------------------+ ---  CFG will provide many
      |  CFG Parser library   |   |- meta-data driven parsers
      +-----------------------+   |    
      |   Individual Parsers  | ---
      +-----------------------+

3. The parser layer(s) are written in Perl and are independent of the above
layers... i .e. no CIM objects used. This allows command line tools on the
local system to interact  with configuration data without the use of the
CIMOM.

4. The use of metadata will still be something about Config4GNU that sets
it apart from  other projects. There are two types of metadata: client-side
and parser-side.

Client-side metadata consists of translated property names, descriptions,
and details  like how to present data. They will be stored in the CIM schema
(.mof files) and in  client-side  form files, wizards, and plugins.
Parser-side metadata consists of  configuration-file mechanisms, and will
currently be stored directly in the parsers in  Perl code. Once enough
parsers have been written to determine what sort of parser-side  metadata is
common, it will be moved into external data files (e.g. in XML format).

CFG will also serve as a central repository for client and parser
meta-data, similar to  CPAN, Rpmfind, etc. Since we hope that distros and
software authors may help by writing  and customizing meta-data, this will
be taken into account by our design.  This is  intended to aide in the
distribution and sharing of meta-data, and not to serve as a  point of
control.


So what this means for our current code/features is:

1) The majority of our parsers will be usable as-is, the migration to WBEM
will occur  mostly in the existing parser library.

2) Our client API will be based on WBEM with optional enhancements.  Normal
WBEM clients  will be able to work with our providers to manipulate
configuration data, but additional  meta-data will be availble to make
CFG-enabled WBEM clients much more robust and  flexible.  Existing CFG
clients will require some changes.  CFG-enabled clients will  fully support
WBEM and also use a client-side library for CFG-specific tasks.

3) Our "middle layer" will be nicely replaced with WBEM.  Our new parser
layer's library  will become responsible for additional tasks previously
managed by our middle layer ( revision control, privilege elevation, etc.) 
The client(s) we write will also take on  additional duties via a library. 
Essentially, we now have a more established client and  server side middle
layer.  Configuration data validation will be performed both by the  client
and parser layers where applicable.

4) Remote configuration editing will be, by default, possible.  This is a
huge benefit  to CFG, as WBEM/CIMOM handles many difficult things for us.

5) Local configuration, especially during system installation, will be
accessible for  scripting purposes both via a CIMOM server and via a basic
interface which will plug  directly into our parser layer.  This will allow
scripts to work just as they did  before, and also provide a way to dump
configuration representations (in XML or some  other easy to
parse/manipulate format).

Basically, we aren't aware of any features we won't be able to handle, and
for the cost  of switching in WBEM, we gain significant progress that will
help us focus on our  specific goals.


What will still make CFG unique is:

1) Our clients and parses will be meta-data driven.  While much of our
data's structure  will now be found in CIM object structures, much still
remains that we will add.  We  will strive to be the best/easiest system to
add configuration capabilities to, just as  before.

2) We will work to help pool resources and reduce duplication of work. 
Supporting WBEM,  a configuration-editing standard, will facilitate this.


What we aim to do in the next month or two:

1) better define needed roles in the CFG project to help encourage others
to participate  and better recognize those who already do

2) Get a basic prototype working

3) Create a draft of what a WBEM-enabled client will provide that regular
WBEM clients  don't

4) Convert the parser library to a WBEM-provider.

5) Determine what meta-data should go in CIM, the client meta-data, and the
parser meta -data.


Jason Long



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