On Tue, Mar 12, 2002 at 09:20:50PM +0000, Philip Martin wrote:
> Karl Fogel <kfogel@newton.ch.collab.net> writes:
>
> > Philip Martin <philip@codematters.co.uk> writes:
> > > Using separate files also allows the information to be shared by
> > > different programs. There is no reason why the proxy setup, say,
> > > should be restricted to just Subversion. This may be what Greg was
> > > alluding to with his ./configure/proxies suggestion, i.e. it is not a
> > > Subversion specific file and may be read by other apps.
Partly that it can be shared, partly for modularity, partly to allow third
parties (apps, simple tools, shell scripts(!)) to maintain it, and a lot for
the human.
Personally, I would much prefer to deal with a 'proxies' config file than to
crawl through a big-ass common file. Since these are all gathered together,
it is quite fine to use multiple files. Things like httpd.conf and smb.conf
can be quite painful. Looking in the dir, seeing 'proxies', then I know
exactly what to hit.
[ of course, I think if our config file ends up being "big-ass" then we've
failed, but smaller is just one of many things ]
> > If the file is in ~/.subversion/, and its syntax is defined by the
> > Subversion developers, then the app has to learn where and how to read
> > it.
lib/ConfigParser.py :-)
> > Given that, wouldn't readability by other apps be as possible for a
> > single big file as for smaller, domain-specific files... (?)
Nope. If an app is going to *modify* a file, then I think it will be
(slightly) easier for that app to deal with smaller files.
> A non-Subversion app will in general only want a small part of the
> Subversion config. Maintaining a "proxies-only" parser should be
> simpler than a "complete-subversion" parser. This assumes the
> non-Subversion app is using its own code, if it can use the Subversion
> libraries to handle the files the problem doesn't occur. Not all
> applications will want/be able to use the Subversion libraries.
I think we can easily say, "if you're going to read our files, then you
should use our code." But I'd much prefer to be *explicitly* compatible with
ConfigParser.py and any similar config-parsing tools that Perl, et al may
have.
The issue is really about knowing the semantics of those files, and writing
them back out.
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.
If you break it out, then the third-party tool only needs to know about the
constraints within that portion.
And I really like the human element...
Consider: we have a *directory* to contain our information. Let's take
advantage of that. Mother configs are most useful when you want to plop a
single config file somewhere, rather than doing a scatter-shot into a
directory or across directories.
SSH and GNOME are both examples of apps that take advantage of subdirs in
the home directory for storing complex config. I can name more :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 12 23:02:27 2002