[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: config files on Windows

From: Branko ÄŒibej <brane_at_xbc.nu>
Date: 2002-03-27 00:45:24 CET

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

-- 
Brane ÄŒibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
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:46:18 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.