| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
On April 22, 2002 10:58 am, William McArthur wrote: |
| 5 |
> Yannick Koehler wrote: |
| 6 |
> > What about a central config file, that would be able to generate all |
| 7 |
> > other related config... gentoo_config.xml, which when transformed using |
| 8 |
> > xslt, would produce conf.d/net, conf.d/ntp, etc... |
| 9 |
> |
| 10 |
> So you just want the windows registry? |
| 11 |
|
| 12 |
Hello Sandy, |
| 13 |
|
| 14 |
Not at all, actually as I reply to Todd Wright in private, |
| 15 |
|
| 16 |
"As for the single configuration file, we may not need it. If we evolve to a |
| 17 |
configuration file that allow software to understand and manipulate it then |
| 18 |
it would solve my issues without breaking yours. |
| 19 |
|
| 20 |
And it would still make the config files small and would encourage |
| 21 |
re-use of tools that can manipulate configuration file. If we use xml we |
| 22 |
juste gain tools that already exists." |
| 23 |
|
| 24 |
The idea that I had originally started with a single file because in my head, |
| 25 |
software needed a location to start reading your configuration. If that |
| 26 |
logical location is a directory such as /etc then fine it would be able to |
| 27 |
retrieve all configurations and deal with them. The missing piece is what |
| 28 |
xml is all about, adding definition to content so that software can be |
| 29 |
written that properly understand and handle its content. |
| 30 |
|
| 31 |
This would still allow automatic merging and application to be written that |
| 32 |
are not bloat and can allow easy configuration of those files while allowing |
| 33 |
advance users to simply go and edit those files. There could even exists a |
| 34 |
deamon that monitor /etc and when a file changes reparse it to generate the |
| 35 |
proper backward compatible config file so that nothing change for advance |
| 36 |
users as well. |
| 37 |
|
| 38 |
It wouldn't even be hard to go back and forth such as the transformation be |
| 39 |
applied in reverse and actually generate the xml file so that they stay in |
| 40 |
synch even after the backward-compatible related cfg gets modified. |
| 41 |
|
| 42 |
Actually that's where I would start, making a system that takes current cfg |
| 43 |
and get them into xml/xslt. Once this gets done then it would be easy to |
| 44 |
reverse the process using existing xml tools and editors. A deamon would |
| 45 |
need to run to maintain them in sync and that would be it. |
| 46 |
|
| 47 |
- -- |
| 48 |
|
| 49 |
Yannick Koehler |
| 50 |
-----BEGIN PGP SIGNATURE----- |
| 51 |
Version: GnuPG v1.0.6 (GNU/Linux) |
| 52 |
Comment: For info see http://www.gnupg.org |
| 53 |
|
| 54 |
iD8DBQE8xCuifuKOJNEyL1URAlPHAJ9uBTCrChWhsu0YUy5rKCAqfmcVdACgo0kN |
| 55 |
85p+3P63ZaTvgV2McZ9QIGw= |
| 56 |
=k8Oi |
| 57 |
-----END PGP SIGNATURE----- |
Archives