Bill Crawford <billcrawford1970 gmail com> wrote:
Dunno where you got this obsession, but just because you can represent data as "key/value pairs" doesn't mean that's always the best layout.
Maybe not for your or my eyes. The best layout is the one accessible by the broadest range of ways. Currently, human-readable files are accessible by human-beings only, or by configuration file "compilers", that are difficult, unique, that nobody wants to write or maintain except for the original software writer (e.g. the Samba developer with the smb.conf file).
The proposed layout is accessible to you by simple reformatting (as with the kdb edit command, http://www.libelektra.org/Kdbcmd#edit) or by GUIs (as kdbedit, http://www.libelektra.org/The_kdbedit_GUI_Admin_Tool), and by any software that uses a simple API as libelektra.
There's a reason why programs aren't written for the old Turing Machine, and that's that however well it might be able to represent any possible program, it's incredibly verbose.
The only reason I can see is historical. Since there is now projects integration efforts in the OSS world, everybody uses its own format. So you may think there is a reason, lost in time, but there is actually no reason why BIND named.conf file look that way, which is different from /etc/passwd, which is different from smb.conf, which is different from httpd.conf. Well, the real reason I can see is selfish developers that enjoy rewriting config file parsing code and invent configuration file layouts that seems best suited for their apps. But when you strip the syntax fat, they all are not more than key and value pairs on a hierarchy.
So to make the discussion productive, please enlighten us with the reasons you think exists somewhere, or please don't speculate.
The examples which have appeared in this thread have all made things *less* clear afaics.
Again, maybe for our human eyes, but are 100% clear for software. And the end-goal is leverage better software integration between themselves, so we, human-beings, will have to look at configuration element everyday less.
Anyway, for human eyes, I think this is pretty pleasant to see: http://www.libelektra.org/Screenshots_and_Key_Examples
Bill"somewhat sick of this thread but suspecting if people don't reply the lunatics will end up running the asylum"Crawford.
Or maybe the lunatics are already running it and some people are trying to take the control back :-)
Avi
On Fri, Mar 31, 2006 at 01:30:12PM -0300, Avi Alkalay wrote:
So you may think there is a reason, lost in time, but there is actually no reason why BIND named.conf file look that way, which is different from /etc/passwd, which is different from smb.conf, which is different from httpd.conf.
...except that configuring a name server is a differnt problem domain than configuring user accounts, than configuring a file server, than configuring a web server, etc.
Please, this topic comes-up again and again. How long this time before someone suggests we all use the windows registry?
Migrating thousands of Unix-oriented applications to XML-based (or similar) configurations schemes, only so that you then have to develop new tools for each application to turn the XML config file into something appropriate for the given application, just makes no sense.
Perhaps you could move-on to actually writing some code to solve a real problem, instead of re-hashing this pipe dream?
Thanks,
John
On 3/31/06, John W. Linville linville@redhat.com wrote:
On Fri, Mar 31, 2006 at 01:30:12PM -0300, Avi Alkalay wrote:
So you may think there is a reason, lost in time, but there is actually no reason why BIND named.conf file look that way, which is different from /etc/passwd, which is different from smb.conf, which is different from httpd.conf.
...except that configuring a name server is a differnt problem domain than configuring user accounts, than configuring a file server, than configuring a web server, etc.
I thought we were talking about the syntax, and not semantics.
Migrating thousands of Unix-oriented applications to XML-based (or similar) configurations schemes, only so that you then have to develop new tools for each application to turn the XML config file into something appropriate for the given application, just makes no sense.
Yeah, this really makes no sense. Thank God we are clever enough to not walk in the path your imagination just described. But it would help if people understand what we are trying to do first, and after that make public criticisms that make more sense than your based-on-nothing statement.
Thank you Avi
On Fri, Mar 31, 2006 at 03:52:10PM -0300, Avi Alkalay wrote:
On 3/31/06, John W. Linville linville@redhat.com wrote:
On Fri, Mar 31, 2006 at 01:30:12PM -0300, Avi Alkalay wrote:
So you may think there is a reason, lost in time, but there is actually no reason why BIND named.conf file look that way, which is different from /etc/passwd, which is different from smb.conf, which is different from httpd.conf.
...except that configuring a name server is a differnt problem domain than configuring user accounts, than configuring a file server, than configuring a web server, etc.
I thought we were talking about the syntax, and not semantics.
Using a syntax that doesn't correspond to the semantics makes things harder, not easier.
Migrating thousands of Unix-oriented applications to XML-based (or similar) configurations schemes, only so that you then have to develop new tools for each application to turn the XML config file into something appropriate for the given application, just makes no sense.
Yeah, this really makes no sense. Thank God we are clever enough to not walk in the path your imagination just described. But it would help if people understand what we are trying to do first, and after that make public criticisms that make more sense than your based-on-nothing statement.
http://www.redhat.com/archives/rhl-devel-list/2006-March/msg01755.html
The best layout is the one accessible by the broadest range of ways. Currently, human-readable files are accessible by human-beings only, or by configuration file "compilers", that are difficult, unique, that nobody wants to write or maintain except for the original software writer (e.g. the Samba developer with the smb.conf file). The proposed layout is accessible to you by simple reformatting (as with the kdb edit command, http://www.libelektra.org/Kdbcmd#edit) or by GUIs (as kdbedit, http://www.libelektra.org/The_kdbedit_GUI_Admin_Tool), and by any software that uses a simple API as libelektra.
I don't know how I got the idea that you wanted to change configuration file formats, then use new tools to make them human readable...
John
On 3/31/06, John W. Linville linville@redhat.com wrote:
Migrating thousands of Unix-oriented applications to XML-based (or similar) configurations schemes, only so that you then have to develop new tools for each application to turn the XML config file into something appropriate for the given application, just makes no sense.
Yeah, this really makes no sense. Thank God we are clever enough to not walk in the path your imagination just described. But it would help if people understand what we are trying to do first, and after that make public criticisms that make more sense than your based-on-nothing statement.
http://www.redhat.com/archives/rhl-devel-list/2006-March/msg01755.html
The best layout is the one accessible by the broadest range of ways. Currently, human-readable files are accessible by human-beings only, or by configuration file "compilers", that are difficult, unique, that nobody wants to write or maintain except for the original software writer (e.g. the Samba developer with the smb.conf file). The proposed layout is accessible to you by simple reformatting (as with the kdb edit command, http://www.libelektra.org/Kdbcmd#edit) or by GUIs (as kdbedit, http://www.libelektra.org/The_kdbedit_GUI_Admin_Tool), and by any software that uses a simple API as libelektra.
This is for exporting, or to make backend independent representation of configuration elements or for your human eyes to see. But for you to manage, or to be "something appropriate for the given application" (to use your words), or for other software to interact with it, direct access to configuration parameters is what will actually happen. You don't need to convert it to XML or anything else.
Regards, Avi
On Fri, 31 Mar 2006, John W. Linville wrote:
Using a syntax that doesn't correspond to the semantics makes things harder, not easier.
Can you give an example? Using a filesystem (i.e. directories, files and file contents) as the syntax for an applications semantics does not affect/decrease the relationship in any of the cases I can think of.
I don't know how I got the idea that you wanted to change configuration file formats, then use new tools to make them human readable...
I think your idea or at least how you are presenting it is incorrect. This thread started with the idea of changing configuration file formats so obviously no one here is saying that is not what is being discussed. However I think your comment on human readable is misleading. There is nothing nonhuman readable or editable (using vim, sed etc...) about directories, files and plain text file content.
Cheers, Shane
Avi Alkalay avi@unix.sh wrote:
Bill Crawford <billcrawford1970 gmail com> wrote:
Dunno where you got this obsession, but just because you can represent data as "key/value pairs" doesn't mean that's always the best layout.
Maybe not for your or my eyes. The best layout is the one accessible by the broadest range of ways. Currently, human-readable files are accessible by human-beings only, or by configuration file "compilers", that are difficult, unique, that nobody wants to write or maintain except for the original software writer (e.g. the Samba developer with the smb.conf file).
That they do anyway (hell, it is the /only/ way to get the configuration for the application!) there must be some reason...
[...]
There's a reason why programs aren't written for the old Turing Machine, and that's that however well it might be able to represent any possible program, it's incredibly verbose.
The only reason I can see is historical.
As they asy around here, there is no worse blind than the one who doesn't want to see...
Since there is now projects
integration efforts in the OSS world, everybody uses its own format.
Non sequitur.
So you may think there is a reason, lost in time, but there is actually no reason why BIND named.conf file look that way,
... which is /totally/ different from the format used not that far back...
which is
different from /etc/passwd,
... which has to describe /completely/ different sorts of things...
which is different from smb.conf,
... which is yet different...
which is
different from httpd.conf.
... and again something else completely.
Well, the real reason I can see is selfish
developers that enjoy rewriting config file parsing code and invent configuration file layouts that seems best suited for their apps.
Sure, there are wheel-reinventation-worshippers around, but it is not as bad as you paint it.
But
when you strip the syntax fat, they all are not more than key and value pairs on a hierarchy.
Really? Or ist it just that everything can be described that way (even if that is not at all convenient, just as Turing machines aren't nice to program)?
So to make the discussion productive, please enlighten us with the reasons you think exists somewhere, or please don't speculate.
Please do show you do understand the differences between configurations syntaxes, and how to overcome them, before you expect us to believe you are on to something useful...
The examples which have appeared in this thread have all made things *less* clear afaics.
Again, maybe for our human eyes, but are 100% clear for software.
System administrators aren't software.
99% of the problem is understanding /what/ you want to do, and /how/ to do it with very complex tools subject to all class of non-intuitive environmental conditions. Finding out how to read and write the configuration files is usually trivial in comparison.
Making complex stuff driven by nice "simplified for normal user" GUIs doesn't make it simple, it just makes it look simple (and the ensuing breakage isn't nice to contemplate).
And
the end-goal is leverage better software integration between themselves, so we, human-beings, will have to look at configuration element everyday less.
This has been the holy grail of system administration from day one. Doesn't look that much closer today, as the job is getting every day more complex while the tools desperately play catch-up.
devel@lists.stg.fedoraproject.org