Re: [gentoo-dev] Config Idea - take 2

[Terje Kvernes]

Yannick Koehler <yannick.koehler@××××××××.com> writes:

> So far what I learned is that the whole system should be optionnal.

  if you're thinking "XML", yes.  it should be.

> It must retain support for existing configuration files for several
> reasons such as working with current applications.  It must not
> gives a feeling of duplication but still provide a comprehensive way
> for software to deal with the various configuration.

  ick.  this sounds a lot like marketspeak.  honestly, the day someone
  starts writing XSLTs for configuration files, I wish them pity.  for
  one thing, adding a single option in a given config suddenly
  requires another DTD.  another DTD which is in no way _really_
  related to the previous one.  maintenance becomes interesting.  the
  XSLT work also has to change.
  
  second, we'd have the issue of verbosity.  writing XML isn't
  something you do easily during emerge.  imagine wanting to port from
  one version of the initscripts to another -- you might just want to
  add one single variable.  we'll need to require a full XML parser
  just to do such a task, instead of adding a line to the end of a
  file.  unless this gives us a very large benefit, I don't see it
  happening at all.

  third.  most configurationfiles are flat.  very flat.  with a very
  loose order.  changing this isn't a good idea in itself, it's not
  needed to change either.  using XML to store a very flat hierarchy
  is usually overkill.

  and fourth, and this is very general.  KISS.  things work very well
  today.  again, if we're going to change it, there should be some
  great promise of good things happening.  again, I don't see it.  :/

> The idea is evolving a little more.  What if the system was not
> going to create files, but was going to apply transformation rules
> from a given folder when reading the file and then parsing it
> internally into xml to then use inside some kind of application like
> merge or configurator.

  whoa.  this would make emerge optionally depend on a full XML
  suite.  fair enough, 4Suite mostly works, but why?  and if it is
  optional, will people use it?  
 
> So you'll have /etc which remains intact, a software that is
> optionnaly installed with a bunch of transformation text file such
> as xslt which would provide instruction to the software on how to
> parse the original file and transform it into an xml one.

  honestly, that XSLT-file I want to see before I will give it much
  faith.  I handcoded XSLT for a long while and I don't see this as a
  trivial task.  how many developers know their XML and XSLT well
  enough to do this (properly)?

> Then using xml tools merge software could be written and xml editor
> used.  The xml then become a software interface and never interfere
> with existing etc folder.

  you'd have to interfere with /etc, otherwise inconsistencies would
  emerge (okay, bad pun :) and all hell would break loose.
 
> What do you think on that one?

  I think it sounds like the debates that happen now and then on using
  XML in /proc on linux-kernel.  it doesn't _give_ as much as it
  demands.  by far.  if anyone can prove the gain from such a change,
  I'd rethink my stance, but so far the idea scares me.  it adds a lot
  of complexity and solves very few problems, if any.  :/

  and no, I don't work with XML anymore.  I happily got away from it.
  two years of trying to make DTDs "fake" inheritance and deal with
  version changes now and then got the best of me.  if I was going to
  rant about XML in general, and not about this specific issue, I'd
  say "XML is very often the wrong solution to the wrong problem".

-- 
Terje