[Config4gnu-developer] Re: J&J reinvent the wheel: they rediscover db & oop :)

[Jason L. <jl...@me...>]

Hopefully it's not so much reinventing the wheel as using existing ideas....

i.e. using an existing database wouldn't help because we want the data to
exist in the native configuration files. Using a database to store the XML
would mean we have two copies of configuration-- the one that's in the
database and the other that's in the original configuration files. However,
this again brings up the question of caching the configuration, in which
case using a database to store the configuration is appropriate.

I do see the project as something along the lines of providing an
object-oriented database _interface_ to the configuration data. But what
should an object-oriented database interface look like?

I agree that Java has a lot of capabilities that will be useful, but I think
creating a dependency on a JVM would be a serious detriment to the
acceptability of our project. JVM's are big, take a while to start up, and
I'm not sure how available they are beyond the Win32, Solaris, and Linux
environments.

Anyways, thanks for the feedback
Jason Long

>>> Gene Chase 11/12/02 12:18 PM >>>
I've caught up with reading your Config4GNU site.  My summary:  "Let's
reinvent the wheel."  :)

Yack says 
>It seems like the sticky point is how to make it easy 
>to ensure that the configuration changes are successful. 
> Maybe a better bash script would be: 

>for host in "host1.com" "host2.com" "host3.com" 
>do 
>echo 'cd /Daemons/Samba/; set "wins server" = "10.13.1.1"; commit;' \ 
>> cfg -H $host 
>done 

----Let's reinvent databases.

Long says 
>Would it be possible to write the generic parsers 
> in a way that they could be extended by more specific parsers.
 
----Let's reinvent object-oriented programming.
 
 
I didn't think db before because the XML files would be small and
infrequently used, so I didn't anticipate any contention.  Your discussion
about assuring that the data are properly written reminds me:  There are
other reasons for db's besides contention,  security and integrity being two
of them.
 
----Would storing the XML in a db help?
 
I didn't think OO before because I didn't read your "samba extends inifile"
example.  This is not quite the same thing as simply redoing C code in C++
because you are not trying to write a parser in an OO language, but rather
writing a parser of* objects.  There must be some way to write parametrized
parsers that don't require creating a new (C++?) class file every time a new
thing to be configured appears.  That would somehow fail to capture a
significant generalization, unless that process too were quite boilerplate.
 
I can imagine a future example in which you want samba to extend inifile,
and also to extend microsoftPassport, and then the extension mechanism
requiring multiple inheritance rears its ugly head.  Even without multiple
inheritance, I can imagine future scenarios in which you might need to
"refactor" your code in the light of new object relationships.  At the
moment Java is the only lg that I know which has tools for automating the
refactoring of OO code.
 
----Would documenting an object hierarchy for the things currently listed at
cs.messiah.edu/~cfg help to determine whether this is a special case that
you should ignore or whether inheritance is so common that it becomes an
essential part of what you're doing?
 
My $0.02 is that there isn't enough OO stuff going on to make it worth the
trouble to think further about it.  At least this year.
 
--gene chase