Re: [PLUG] Config Files and Steam Engines

[Dan Widyono <dan@widyono.net>]

Hi Brian,

>    At the same time, I must also point out two other things: 
>    (1)  I don't think it's 100% fair to blame the said flaw on the registry. 

I agree COMPLETELY with that statement.  In fact, I could care less about the
registry in this discussion.

What I meant in my reaction to your bringing up the registry was: using it as
an example of how or why syntax needs to improve, merely hinders your
argument, IMHO.  I'm simply trying to help hone in on what would move this
conversation forward.  I feel bad for the effervescing eclipsed equine, you
know.

One problem I have with this entire conversation is I haven't read any
shining example of a good configuration API that has consistently improved
syntax across multiple diverse vendor products (on one OS, much less across
multiple OSes).

Even though Windows provides a Registry, it really doesn't do much of
anything with respect to what Matthew wants; rather, it just enforces typing
in a very useless way because there is no DTD, no spec, no good explanation
(AFAIK; I'm not a Windows programmer, but a quick google search did not
inspire confidence in finding much) of what to do with the types.  As an
example, there ought to be a REG_DATE instead of a REG_SZ with a date inside
it; that should be explicitly defined and explained to programmers.  Perhaps
an ODf for configuration files.  *That* is what really is necessary in order
to start achieving what Matthew wants.  The API should then arise organically
from that standard specification (or worked on in parallel, but the API
should follow the spec).

So, long story made short: to discuss syntax consistency, focus on specs, not
e.g. the horrid Registry implementation which does nothing to improve the
situation (reminds me of MS OOXML, but that's a whole other can of worms).

>    (2)  The overall message that I was trying to get across was that, though
>    it is commonly misused, at lease Windows and OSX provide *some sort* of
>    framework for doing the things that Matthew is describing.

I agree.  In Linux there is no standard library framework for such work.
That could enable useful further interactions, and that's speaking as a
manager (policy driven), as a sysadmin (consistency, reproducability, and
maintainability), and as a user (ooh look, turn this dial and that happens!).
I assume programmers would love having another library to play with.  :)

Cheers,
Dan W.
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug