Jay Freeman (saurik) wrote:
>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.
Nonsense. I wrote such an editor (or read-write parser) in a week, and
could convert this one in less. What's more, the format we have now is
the same as the one used by Python's ConfigParser module.
> 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
>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.
That only makes sense if you use a validating XML parser, which we do not.
Now, before we start an XML-vs-WhatWeHave flame war: it is entirely
feasible to embed XML into our config files, without changing a single
line of code in the parser.
>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
>About your pretty printing argument, you obviously aren't using a good XML
>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?
>Jay Freeman (saurik)
>----- Original Message -----
>From: "Bill Tutt" <firstname.lastname@example.org>
>To: "'Jay Freeman (saurik)'" <email@example.com>; "svn-dev"
>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
>>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
>>Machine generated XML files (esp. those generated via using a DOM-like
>>object model) aren't generally known for generating human editable
>>(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
>>Besides, how many configuration files do you know that need to be
>>queried 27 different ways from Sunday using complex XPath, or indeed
>>More to come about what I think we should do for Windows in a response
>>to Branko's email.
>To unsubscribe, e-mail: firstname.lastname@example.org
>For additional commands, e-mail: email@example.com
Brane ─îibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Mar 27 00:46:18 2002