The problem with the ini file formats for these things is that ini files
aren't that great at parsing and editing by a configuration manager should
one ever become available. It isn't just about comlexity of queries, it's
about complexities of edits. An example of an issue: ini files don't have
a way to check consistency. I've been going back trying to find
conversations about the configuration system (it seems a lot of this came up
in a recent thread about configuring http proxies). There is a comment made
by Greg Stein:
<quote src="Greg Stein">
For example, the proxy configuration has internal integrity constraints. If
you define a group, then you have to associate some items with *that* group.
Other portions of our config (certs? default user/pass?) will have their own
constraints. By lumping all the config into a single file, then you require
the app to know *all* of the internal, integrity constraints of the mother
config file.
</quote>
Well, while the tool that is reading this still needs to know that, things
do become a lot easier when you have the hierarchial element (looking at the
simple sample file in my ~/.subversion directory, it sure seems this would
be the case). Also, you could have a DTD that verifies that groups contain
at least one proxy.
Skimming a sample of some of the other e-mails (will need to go back and
really read them), there was also an issue involving how multiple entries
will be seperated. There was an entire thread born from this about commas
versus spaces, and someone mentioned (and it seemed to stick) having a
function people would call to do the conversion. Umm... yet there was also
mention about letting the file be easily used by people who aren't
subversion (in which case requiring a Subversion function as an abstract
seems entirely out of the question). If there were a simple, general XML
config file for proxies that had parsing semantics that didn't involve
searching for special characters to split entries (example: this case should
have multiple tags for each of the host entries in a group) this wouldn't be
an issue.
About your pretty printing argument, you obviously aren't using a good XML
serializer :).
Personally, I'd _rather_ hand edit in vi the XML equivilant of that rather
verbose ini file I'm seeing. The referential integrety issues of this ini
file aren't just visible to a machine parser, but are visible to me as well.
I have to have the names of groups in two places in the file, the hosts that
a proxy serves can be quite far away from the actual proxy configuration...
what is better about editing this than editing a hierarchial XML file?
Sincerely,
Jay Freeman (saurik)
saurik@saurik.com
----- Original Message -----
From: "Bill Tutt" <rassilon@lyra.org>
To: "'Jay Freeman (saurik)'" <saurik@saurik.com>; "svn-dev"
<dev@subversion.tigris.org>
Sent: Tuesday, March 26, 2002 4:59 PM
Subject: RE: Re: config files on Windows
...> It's all about the file editing environment. Forcing people to hand
edit
> XML files via vi, Emacs, or any favorite editor of your choice just
> isn't a very nice thing at all.
>
> The Subversion folks aren't about to stick a UI to edit the
> configuration file in 1.0. They're simply too busy doing everything
> else.
>
> Machine generated XML files (esp. those generated via using a DOM-like
> object model) aren't generally known for generating human editable
> output.
> (i.e. no pretty printing, and no line feeds)
>
> Thus the choice for INI files. They might not be hierarchical, but
> they're really easy to edit and it drastically reduces the need for an
> editing UI.
>
> Besides, how many configuration files do you know that need to be
> queried 27 different ways from Sunday using complex XPath, or indeed
> XQuery queries?
>
> More to come about what I think we should do for Windows in a response
> to Branko's email.
>
> Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 27 00:16:31 2002