Alternative format for the configuration file

[Free Ekanayaka]

|--==> "OS" == Otavio Salvador <otavio@debian.org> writes:

  OS> [1  <multipart/mixed (7bit)>]
  OS> [1.1  <text/plain (7bit)>]
  OS> || On Tue, 27 Jul 2004 09:21:51 -0400 (EDT)
  OS> || "Nathaniel L. Budin" <natb@brandeis.edu> wrote: 

  nlb> On Tue, 27 Jul 2004, Otavio Salvador wrote:
  fe> and some  very  easy   to fetch variable    values with  a  dictionary
  fe> approach,  like   Cnf["APT::Get::Arch-Only"]  to get   the  value from
  fe> apt-get.conf.
  >>>
  >>>The way to read the file is a lot easier since APT already does it and
  >>>we can use this format without a parser but this, for a not so
  >>>experiensed user, looks more complicated and long. This is what I
  >>>think.

  nlb> I'm not sure it'll be as easy as you think.  The most difficult part, IMO, 
  nlb> of the current parser, was the variable configuration keys; for example, 
  nlb> "filter_sarge" in a merge backend.  We'll still need to have those 
  nlb> supported, which I doubt the parser for this format already supports.  
  nlb> (Not that I've checked, but I don't imagine it would.)

  OS> I forgot it.

Are variable configuration keywords  really necessary? Actually  I did
not  realised that the  "_sarge"  suffix was  refering to  the [sarge]
section until I read the above lines (well I guess  it in some part of
my brain, but it's a  little bit unusual  for configuration files so I
dropped that thought).

I don't know what the filter_sarge keyword  is supposed to do exactly,
but I   think it can be   replaced by static   keyword,  like filter =
sarge:section:base or something similar.

Whatever   config format we  choose,   IMHO we  should avoid  variable
keywords.

  >>>The configuration file looks very clear and flexible to me but I
  >>>doesn't know how much this format will improve the flexibility. This
  >>>is what we should think.

  nlb> I also don't think this new format buys us very much in terms of 
  nlb> flexibility.  True, the structure is hierarchical instead of flat, but I 
  nlb> don't think a hierarchical format is necessary for a simple, one-task tool 
  nlb> like debpartial-mirror.

  nlb> As for compatibility with other apps - even if we switched to this format, 
  nlb> I doubt you'd be able to use the same config files between APT and 
  nlb> debpartial-mirror anyway, so I'm not sure where the perceived 
  nlb> compatibility gain is coming from.

Yes, I didn't  claim compatibility with other  APT tools. It's just to
have a consistent format between them.

Regarding simplicity, I  think there  is  room for  improvement in the
schema I proposed,  however   I  think  that good  documentation   and
meaningful comments can make everybody happy.

Cheers,

Free Ekanayaka