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

[Yannick Koehler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On April 22, 2002 06:49 pm, Terje Kvernes wrote:
>   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.

I have not heard about marketspeak, I will proceed with some research to see 
how it fit inside my idea, thanks.  I'd like more details on the thought that 
you mention about a single option inside the config may require a whole new 
DTD please so that I can validate that case and see how often it could occurs 
and if there's anything existing that allow to go around it.

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

Again, please give me concrete example as I don't understand how adding a 
variable will cause a need for a parser as XML is quite easy to use without 
such parser.

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

You have to understand that I'm not going to replace a flat text file into an 
XML file just for the sake of it.  Actually in the current state the flat 
file will be on the fly converted into an XML logical representation which 
could be save as-is but most likely will not.

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

That may be true for you but not for me.  The current state of the 
configuration system still take up to 20 min. of my time to ensure config are 
merged and their results is ok.  That is for sure relative on which package I 
uninstall/install and will be different for everyone of you.  I actually 
don't promise good things yet as I'm still very early and looking at the 
details of what this represents and to evaluate if at the end the solution 
will solve my current problems.  

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

!?  Not sure I get your point here.  There'll be 1 package which portage will 
not depend on but when present portage could use.  I believe that this would 
be set using a keyword inside the USE variable and I have yet no idea as what 
will be inside that package and the size of it.  It will be for sure a goal 
to keep it small and make it fast as with most software I work on, but the 
primary goal will absolutely be to solve my issues such as 
merging/unmerging/ease creation of config tools and at some point mix that 
with an install tool.

>   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)?

I am not an XML/XSLT expert myself but I have learned in one day how the basic 
system work and got a small example running with a single tutorial.  There 
seems to be plenty of those on the web and as more and more linux software 
use XML, such as Web/Mozilla/KDE/Gnome etc., it makes me believe that there 
will be a lot more tools related to those technologies in the very near 
future.

XSLT doesn't seems to fit my idea of a general purpose transformation 
languages as it seems to require an XML tree at the source to generate an XML 
tree at the output.  Something I'm thinking about is tranforming the flat 
config into a keyword XML tree without processing instruction and then 
applying templates on them, then reverse the process.  But that's too early 
to confirm XSLT will be up to the task.

I also have to make it a big point that the way the system is done it would 
attract developer by its ease of use.  And that's a point I need to work on, 
how I will get that as simple as bash (well, actually that may be easy ;-)).  
Maybe the kind of person who will help in that sector won't be ebuild 
developers but web developers, which could possibly be a greater number of 
people as I believe there's more web developer than there is bash developer 
but that's not a fact but a thought.

>   you'd have to interfere with /etc, otherwise inconsistencies would
>   emerge (okay, bad pun :) and all hell would break loose.

For sure I will have to modify /etc content but again that will only be if you 
use the tool.  There's no point in making the system transform the /etc into 
an XML logical representation to merge new config and then discarding the 
results.  I could easily make it output to a different folder and let you 
switch between them to test.  That could be a good way to let people 
understand how the system works and to test it by having input, output and 
merged and do compare.

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

Yes it does, but sometimes the benefit cannot be understood until the system 
is actually in place.  Right now I see ease of merge with ease for software 
installation and from a point of view of an administrator or a developer 
those means nothing as he's doing there steps and they are happy with the 
current state.  For that to make sense you need to get at a different level 
where the user is presented and they set up their system.  If you want them 
to go use some other distro fine but you can't force them, I'd actually like 
that more people use gentoo even if they don't know all about Linux, first 
they can learn (yes even with such an idea as I got) and they'll generate a 
demand on you guys to continue to keep the pace with creating ebuilds.  

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

I can't argue with you as I have no experience (except 1 day) with XML.  I'm 
based myself on the description/purpose of those languages and from what I 
experienced with them.  That languages has been made as I understand to allow 
software to understand content other than their mime-type.  From that point 
on software can do mostly anything and that's probably why it has not taking 
off yet as it has not been clearly define what the software can do as there's 
no limitations.

Some additionnal things that I could add as a secondary goal to the config 
system could be to remotely configure it or to configure multiple computer at 
the same time while only modifying certain parameters that are really system 
specific that may help on the clusterisation etc...  If software understand 
what attribute are unique per PC and which could be duplicated on all PC then 
you make it feasible to have central configuration for all your PC without a 
single duplication in your configuration tools (the duplication exists 
thought when you press the 'do it' button and that it generate the /etc in 
the different PC but that may even dissappear if people get to like XML)

- -- 

Yannick Koehler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8xWXmfuKOJNEyL1URAuEWAKCPUzIwBrhi3CVHBcJ6PvtGd6X1LgCfQWrX
h9RtW8WDvlPTyWl1cihQi5g=
=satu
-----END PGP SIGNATURE-----