| View previous topic :: View next topic |
| Should configuration syntaxes be harmonized? |
| Hell! No! It's good enough as it is now! |
|
26% |
[ 8 ] |
| Not sure. Why would we? |
|
26% |
[ 8 ] |
| Yes |
|
16% |
[ 5 ] |
| Yes, plus provide a shared library for application developers |
|
16% |
[ 5 ] |
| No, just provide libraries for a few syntaxes |
|
13% |
[ 4 ] |
|
| Total Votes : 30 |
|
| Author |
Message |
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
 Posted: Thu May 15, 2008 10:30 am Post subject: Should configuration syntaxes be harmonized? |
 |
|
Hello. I started this poll after having posted a few comments upon OpenRC.
To summarize it all, the thread started from a question about using another syntax for configuring OpenRC. That thread was a reather open discussion as I didn't strictly stick to OpenRC. Having thought a little further I also applied my suggestion to the current state of configuration syntaxes for various applications.
Hence the initial thread was split in two parts: one for posting comments about the idea of using XML for OpenRC and this one. This thread discusses the current state of applications configuration syntaxes.
There are currently various syntaxes used for configuring applications. Most simple are shell-like configuration files; for instance:
| Code: | # One line comment
// Comment, one-liner
/* Block comment */
variable value |
or
| Code: | # One line comment
// Comment, one-liner
/* Block comment */
variable=value |
Also note the various comment syntaxes. Should we keep them all?
There are also ini-like syntaxes, with sections and keys:
| Code: | [section]
; Comment (ini-like)
key=value # Comment (shell-like) |
Also note comments syntaxes. Should we also keep them all?
KDM, GDM, XDM, Wine and samba, for example use that kind of syntax. BTW Wine has extended the syntax dealing with sections for its registry files. One advantage of such a syntax is about having sections. Sections typically group keys into blocks, each block typically represent a scope. Typically, keys must be unique within the same section so there might be several keys with the same name but belonging each to different sections.
There is also a bracketed syntax, which we typically find in BIND and DHCP packages. It ressembles C syntax for structures:
| Code: | section [attributes] {
keyword [attributes] [values];
// Comments...
sub-section [attributes] {
...
};
};
... |
One of the advantages of the latter syntax over the other ones is nesting sections. This provides a hierarchical data representation but in a much simpler way than XML, which is often disliked when interfacing with humans.
Given the amount of syntaxes used all over the place, the idea here is to put a little more order whenever possible. Configuration files are typically edited by the people who install the corresponding package, by humans in general. Hence the syntax must be kept clear and ovbious, yet documented.
I'm not necessarily suggesting one should keep only one syntax. I'm just asking if you consider there is a need to harmonize configuration syntaxes. Should there be also a shared library that would take care of the syntax(es) and provide application developers with a set of functions to read/set configuration data, thus eliminating the need for every application to embed the same code over and over again?
For instance, webmin would be able to read/set data from/to any other configuration file without requiring the managing code to be implemented in each module. Applications would be able to share the same code library for handling configuration data. Static link should also be possible.
A shared library would kind of standardize how applications read and write from/to their configuration file(s). The purpose of such a library is also as ambitious as to serve other distributions, not only Gentoo.
Note the syntaxes I described here do not mean to be normative. They're just a short summary of what currently exists.
Please feel free to comment while voting.
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
| Back to top |
|
 |
LJM9000
Tux's lil' helper
Joined: 31 Aug 2006
Posts: 76
Location: United States
|
| Posted: Thu May 15, 2008 2:11 pm Post subject: |
|
|
| IMHO it'd be weird if you changed it. Thats the way its always been. But if it does change not like its a real show stopper unless current configs are not supported. Then there will be a lot of people unhappy. |
|
| Back to top |
|
|
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
| Posted: Thu May 15, 2008 7:16 pm Post subject: |
|
|
| LJM9000 wrote: | | IMHO it'd be weird if you changed it. Thats the way its always been. But if it does change not like its a real show stopper unless current configs are not supported. Then there will be a lot of people unhappy. |
If you think there would be changes then consider the idea of a globally shared library, which would hanldle commonly used syntaxes. Since anybody would be free to link against that library or not, why would there be unhappy people at all? That's the fifth option.
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
| Back to top |
|
|
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 9523
Location: beyond the rim
|
| Posted: Thu May 15, 2008 9:47 pm Post subject: |
|
|
Different applications have different needs for their config files. The easiest way way to configure an shell script based application is by sourcing another shell script. Sure you can write a few tools to parse other syntaxes, but that's complicated and unflexible (e.g. you'd loose variable substitution and other typical shell features). Other applications might care about strict compability with windows .INI files or other systems they can't influence. On the other hand small projects often only need a simple key-value syntax, so some hierarchical system would just complicate things unnecessary. Then you also have to look at what systems are included in different programming languages (as esp. small projects like to avoid additional deps).
Now, in some cases it might make sense to unify formats that only have minor differences, or where one variant is a complete subset of another, and none of the above reasons applies. But even then you still have migration and compability issues (e.g. whenever we add new syntax features to portage config files, third-party tools often break and require some time before they support them too), which requires support resources (so the work isn't done with a patch).
As for some API to read/write different config file formats, you might want to take a look at libconf.
But in the end, it's all up to the maintainers of the individual projects. If you think that one project could change it's config syntax to something more common, you'll have to convince them and their clients/users that it's a good idea. Writing the ultimate(TM) library for config files is completely useless if nobody is going to use it, and generally people won't change their projects if there is no practical benefit to them. |
|
| Back to top |
|
|
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
| Posted: Fri May 16, 2008 9:45 am Post subject: |
|
|
| Genone wrote: | | As for some API to read/write different config file formats, you might want to take a look at libconf. |
I've tried to check that up but I'm going in circles on their web site, can't find what it does exactly and what syntaxes it supports. Only that it's written in Perl. Links to libconf from http://savannah.nongnu.org/projects/libconf/ are dead ends. There was also a Gentoo Newsletter (but in 2005) that talked about libconf but the link (libconf.net) is also a dead end or doesn't provide obvious hints about libconf. Don't know if I hit the right place though.
If it's what I'm thinking of, it might as well be what I suggested last.
| Genone wrote: | | Different applications have different needs for their config files. The easiest way way to configure an shell script based application is by sourcing another shell script. Sure you can write a few tools to parse other syntaxes, but that's complicated and unflexible (e.g. you'd loose variable substitution and other typical shell features). Other applications might care about strict compability with windows .INI files or other systems they can't influence. On the other hand small projects often only need a simple key-value syntax, so some hierarchical system would just complicate things unnecessary. Then you also have to look at what systems are included in different programming languages (as esp. small projects like to avoid additional deps). |
This is also why I didn't really want to replace syntaxes or provide a unique syntax for everybody but provide a shared library that would support the most commonly used syntaxes. Unification would then take place in how projects use syntaxes: either by writing their own code or linking with the library.
Sure it also raises the question: what languages would be supported... I'm lacking knowledge in other programming languages than C/C++ to provide an answer that would make sense...
| Genone wrote: | Now, in some cases it might make sense to unify formats that only have minor differences, or where one variant is a complete subset of another, and none of the above reasons applies. But even then you still have migration and compability issues (e.g. whenever we add new syntax features to portage config files, third-party tools often break and require some time before they support them too), which requires support resources (so the work isn't done with a patch).
But in the end, it's all up to the maintainers of the individual projects. If you think that one project could change it's config syntax to something more common, you'll have to convince them and their clients/users that it's a good idea. Writing the ultimate(TM) library for config files is completely useless if nobody is going to use it, and generally people won't change their projects if there is no practical benefit to them. |
Well, I often saw so much energy wasted in reinventing the wheel -- I'm only talking about my personal experience and my own experience as an (ex-)windows developer. I realized soon that the Open Source world takes much of its strenght by sharing what's been invented, instead of fighting for keeping secrets. When you do develop proprietary software, you often find yourself reinventing the wheel -- either because of patented/protected code or for various other reasons.
Having spent more than 4 years with GNU/Linux, I noticed so many pleasant facets in various disciplines: system design, development aso. I found it was too bad that with such a strength Open Source software projects had to spend energy and efforts with the configuration part. I thought something had to be done.
But it's maybe non-significant compared with the rest...
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
| Back to top |
|
|
Akkara
Bodhisattva
Joined: 28 Mar 2006
Posts: 6702
Location: &akkara
|
| Posted: Fri May 16, 2008 10:27 am Post subject: |
|
|
I had sometimes wondered why lisp-like S-expressions never became more popular. Fully general and ridiculously easy to parse. Agree on some quoting rules for strings containing whitespace or parenthesis and you're done.
| Code: | (module1
(key1 value1)
(key2 value2)
(key3 value3 (alternate-option1))
) |
More complex systems that don't mind a dependency on a tiny-lisp variant (or those with emacs already installed  ) could get full eval power. |
|
| Back to top |
|
|
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
| Posted: Fri May 16, 2008 1:38 pm Post subject: |
|
|
| Akkara wrote: | | I had sometimes wondered why lisp-like S-expressions never became more popular. Fully general and ridiculously easy to parse. Agree on some quoting rules for strings containing whitespace or parenthesis and you're done. |
It looks very similar to the bracketted syntax used by BIND/DHCP -- if you don't pay attention to the relative position between the block opening symbol and name. (I unfortunately never "played" with LISP.)
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
| Back to top |
|
|
VinzC
Watchman
Joined: 17 Apr 2004
Posts: 5098
Location: Dark side of the mood
|
| Posted: Sat Jun 07, 2008 3:21 pm Post subject: |
|
|
Well 20 votes is not that much but it looks like opinions are balanced between no change, harmonization and libraries. Currently: 6 votes for no change, 7 for a change in total, 7 for shared [set of] libraries.
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
1739! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
