On Tue, Mar 12, 2002 at 02:43:24PM -0600, Karl Fogel wrote:
>...
> * We can't really do cross-file variable expansion, so multiple
> files will probably mean repeated information, hard for the user
> to keep in sync.
IMO, the benefit of variable expansion is very minor. Establish use cases
before determining whether this is truly a problem.
For example, I don't believe that you're going to share variables across
*semantic* boundaries (almost by definition). If we slice config files along
semantic boundaries, then (ergo) we don't need to share variables across
files.
> * In the multi-file way (in Greg's second .subversion/proxies
> example, for instance), we end up with section names based on
> user parameters. What if these conflict with Subversion-specific
> section names?
Too bad for the user. The file simply has a set of reserved sections. The
user avoids them. No big deal.
> This is easier to avoid in a single file, because
> the alternative to dividing by files is to divide by sections --
> leaving prefixes ("group1_") within a section to do further
> subdivision. While that's not perfect, at least it helps us
> restrict the user-affected namespace to something below the
> section level, which may make it easier to avoid accidental
> ambiguities.
I find this hard to buy. ViewCVS has pretty complex config (or used to, it
has grown simpler recently), and at its height, it only had about six or
seven sections. ViewCVS also does the "virtual host" like thing with the
user-defined section names. I've never heard of anybody complaining about
conflicts.
> * It's somewhat simpler to implement the one-file way.
Not necessarily. If you chunk *all* the config into a memory structure, then
you're going to have to start passing that structure everywhere. If you
subdivide the configs, then each module can grab its own config, without
needing to worry about "how do I get access to my data from the mother
config?"
>...
> I guess I'll do this: start down the single file road in the code,
> while continuing to watch the list for feedback.
Getting the HTTP proxy stuff into ra_dav is much more difficult than reading
the config.
Hmm. Actually, that isn't necessarily true. I figured there would be a lot
of work to pass config info across the RA interface. But if the config comes
from a "proxies" file, then it can be completely isolated to ra_dav.
In that sense, all of your config reading, processing, and proxy-setting is
entirely confined to libsvn_ra_dav/session.c
Ooh. I like that a ton.
Because of the possibility of complete isolation of the proxy config stuff
to ra_dav/session.c, then I'm a definite -0 or even -0.5 on the
single-config approach. Unless I'm missing something, it seems to be a clear
win to have a config file just for proxies, which is ra_dav specific.
[ note: I don't know how to handle cmdline switches for proxies; I might
suggest that we /not/ have them, and defer proxy support to an environment
variable and the config file; otherwise, *every* command is going to grow
new proxy options in its "help" screen ]
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:29:58 2002