| View previous topic :: View next topic |
| Author |
Message |
VinzC
Veteran
Joined: 17 Apr 2004
Posts: 2787
Location: Liège (Belgium)
|
 Posted: Wed May 07, 2008 12:25 pm Post subject: Underscore nightmare... |
 |
|
Hi.
I appreciate the work and secretly expected Gentoo was the only one distribution to get faster than others... earlier than others  . Thanks for the job. I haven't tried OpenRC though. I have a suggestion.
Why not use XML to store configuration parameters? In general I hate to arbitrarily push XML to users for they might not be as XML aware as one might think but in this particular case, IMHO, XML is more than appropriate. For example:
| Code: | | module_cx88_dvb_args_2_6_23_gentoo_r5="video_br=2" |
might seem more cryptic than an XML form:
| Code: | <modules kernel-pattern="2.6"><!-- Default kernel pattern -->
...
<module kernel-pattern="2.6.23-gentoo-r5" name="cx88-dvb" arguments="video-br=2"/>
<module name="usbserial" arguments="vendor=0x1410 product=0x2110"/>
...
<module name="ieee1394" arguments="debug"/>
<module name="ohci1394"/>
...
</modules> |
XML parsers accept single quotes for attributes:
| Code: | ...
<module name='mymodule' arguments='param1="my very own string"'/>
... |
Advantages?- syntax is intuitive
- attribute ordering doesn't matter (vs module_cx88_dvb_args_2_6_23_gentoo_r5 or module_cx88_dvb_2_6_23_gentoo_r5_args)
- element ordering doesn't necessarily matter
- hyphens can be used (EDIT: in names and values)
- no nightmarish underscore
- mix between single/double quotes
- uses well-known regular expressions
- decoding must certainly be easier to code (IMHO)
- requires a single XSLT to be transformed back into the initial syntax internally (i.e. parsing code is *unchanged*)
- others than I didn't think of yet...
Wouldn't it be nicer?
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
Linux user #369763 |
|
| Back to top |
|
 |
Monkeh
Veteran
Joined: 06 Aug 2005
Posts: 1472
Location: England
|
| Posted: Wed May 07, 2008 5:12 pm Post subject: Re: Underscore nightmare... |
|
|
| VinzC wrote: | | Why not use XML to store configuration parameters? |
Because the whole point of the work which went into openrc was to provide an rc system which only required one thing: A POSIX compatible shell. |
|
| Back to top |
|
|
VinzC
Veteran
Joined: 17 Apr 2004
Posts: 2787
Location: Liège (Belgium)
|
| Posted: Wed May 07, 2008 10:42 pm Post subject: Re: Underscore nightmare... |
|
|
| VinzC wrote: | | Why not use XML to store configuration parameters? |
| Monkeh wrote: | | Because the whole point of the work which went into openrc was to provide an rc system which only required one thing: A POSIX compatible shell. |
Then you'll have to explain to me what this means. I'm sorry I don't understand that concept. And I don't understand in what a POSIX-compliant shell would ban XML in such a case (i.e. store module information along with kernel patterns and arguments, nothing more), knowing you can already recover your module configuration file manually... It's just that I don't understand what POSIX-compliant means and what it has to do with an eventual XML file just storing module information.
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
Linux user #369763 |
|
| Back to top |
|
|
VinzC
Veteran
Joined: 17 Apr 2004
Posts: 2787
Location: Liège (Belgium)
|
| Posted: Thu May 08, 2008 3:42 am Post subject: |
|
|
Ok, if this is all about keeping the intial code unchanged, then what about this suggestion:
Keep OpenRC module configuration file. And if there is an XML configuration file, then that file becomes the master file from which the configuration gets generated. In other words: if there is no XML file (with modules and arguments) then the initial one from OpenRC is kept.
If there is an XML file with the configuration as I suggested, then it is transformed, using XSLT, to create the initial configuration. Example:
| Code: | if [[ -f /etc/conf.d/xml/modules ]]; then
# Apply XSL transform on /etc/conf.d/xml/modules and store the results
# overwriting /etc/conf.d/modules.
fi
# Process /etc/conf.d/xml/modules normally
... |
Would it be an acceptable solution?
The directory /etc/conf.d/xml is just anotehr suggestion; it could as well be /etc/conf.d.xml/, /etc/conf.xml/, /etc/conf.x/, whatever...
I'm just trying to be positive. If you believe I'm plain wrong, tell me but, please, explain why for I'd like to understand.
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
Linux user #369763 |
|
| Back to top |
|
|
steveL
Veteran
Joined: 13 Sep 2006
Posts: 1140
Location: The Peanut Gallery
|
| Posted: Thu May 08, 2008 7:44 am Post subject: |
|
|
| XML sucks for config info (and a lot of the other uses it's put to imo.) |
|
| Back to top |
|
|
dnadesign
Apprentice
Joined: 23 Dec 2006
Posts: 152
Location: Poland
|
| Posted: Thu May 08, 2008 8:39 am Post subject: |
|
|
| steveL wrote: | | XML sucks for config info (and a lot of the other uses it's put to imo.) |
That's you opinion. I use XML a lot and it's suitable for many tasks... From configuration, through AJAX to web services. It's very flexible and intuitive (well, at least when you're not using namespaces  ).
But still implementing XML config files would require either adding a xml library to openrc or eventually implementing a simple XML support by hand. Sadly each option has it's downsides for OpenRC (the first one is that OpenRC would be dependent on a xml library, which can be non-existent on a fresh system, the second one: reinventing the wheel...).
_________________
Intel Core 2 Duo T7700 @ 2.4GHz
4GB RAM DDR2
nVidia GeForce 8600M GT, 512MB DDR3
Seagate 160GB HD, 7200 RPM, SATA300
Gentoo 2007.0 AMD64, Windows XP Prof. (for gaming mostly) |
|
| Back to top |
|
|
Monkeh
Veteran
Joined: 06 Aug 2005
Posts: 1472
Location: England
|
| Posted: Thu May 08, 2008 9:11 am Post subject: |
|
|
| VinzC wrote: | | If you believe I'm plain wrong, tell me but, please, explain why for I'd like to understand. |
OpenRC has to be fully functional with nothing more than sh (not bash, tcsh, zsh, or other shells.. just sh) and the basic C libraries (as far as I know). It cannot rely on external software like an XML parser. |
|
| Back to top |
|
|
VinzC
Veteran
Joined: 17 Apr 2004
Posts: 2787
Location: Liège (Belgium)
|
| Posted: Thu May 08, 2008 10:03 am Post subject: |
|
|
| VinzC wrote: | | If you believe I'm plain wrong, tell me but, please, explain why for I'd like to understand. |
| Monkeh wrote: | | OpenRC has to be fully functional with nothing more than sh (not bash, tcsh, zsh, or other shells.. just sh) and the basic C libraries (as far as I know). It cannot rely on external software like an XML parser. |
I see. But my second suggestion makes the XML parser just optional and the code doesn't change - ok, just a little but it could offer an optional behaviour with a USE flag, couldn't it? With my second suggestion, OpenRC remains functional with just a sh. An optional -xml USE flag - for instance - would just add, for those who'd want to and I'm sure I'm not the only one.
Since the whole point of GNU-Linux is to be customizeable, why not include such an optional feature, already? You'd tell me I could code such a functionality and include the patch in some overlay but if it can be done a la Gentoo, why not jump onto the opportunity?
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
Linux user #369763 |
|
| Back to top |
|
|
VinzC
Veteran
Joined: 17 Apr 2004
Posts: 2787
Location: Liège (Belgium)
|
| Posted: Thu May 08, 2008 11:11 am Post subject: |
|
|
| steveL wrote: | | XML sucks for config info (and a lot of the other uses it's put to imo.) |
I retain the sentences
| Quote: | | It is not human-readable. |
| Quote: | | It is not efficient. |
This is completely untrue since that assertion is in absolute contradiction with the XML specifications. XML is by definition human-readable *and* machine-readable. However it is true, like with HTML, that it's possible to provide badly designed or written XML. XML doesn't necessarily mean human-readable if one doesn't take the required precautions.
Of course a 200KB XML stream is far less readable than a 1-2KB stream. A 1KB base-64 XML stream is far less friendly than a 10KB, properly indented XML document. It all depends on what you do with XML. XML offers no guarantee that people will actually write good-looking XML or use it with common sense.
It's also true that there are good and bad usages of XML. I've always fought the idea of XML databases for instance. But this is only an extension of what I wrote previously about the length of a good XML file.
Also saying XML is inefficient is completely untrue. That assertion draws a conclusion that is based only on the bad cases. There are good cases for which XML applies. But not everybody catches the good ways. Just like you can as well use your fork instead of your knife to cut your sausage into small pieces, you can use XML to store 200GB disk backups. You can doesn't necessarily mean it's a good idea, which is what people must pay attention to. Only humans make a bad usage of XML. Not every developer follows the best practices; so blame it on people, don't blame it on XML.
The example of a mount point is also not the best example one could have written:
| Code: | <mount>
<device>/dev/hda1</device>
<point>/</point>
<type>ext3</type>
<errors>remount-ro</errors>
<dump>0</dump>
<pass>1</pass>
</mount> |
XML also defines attributes. Decomposing a syntax into elements is not always the best way to go. XML also has its lot of design recommendations. When you have worked about 2 years on standardizing XML schemas for international companies, you give more of your attention to good design. Example:
| Code: | | <mount device="/dev/hda3" fs-type="ext3" options="defaults" ext3:errors="remount-ro" dump="0" pass="1">/var</mount> |
if you consider mount /var. It's just *one* example though. There are plenty of others.
Similarly, saying XML is not human-readable is nothing but a personnal opinion. XML just allows for writing just about anything you want. There are good ways and bad ways to use XML. XML, like many other languages, has no limits but the creativity of those who use it.
Saying XML sucks is like assuming nobody can write proper XML. I don't subscribe to this point of view.
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
Linux user #369763 |
|
| Back to top |
|
|
evvk
n00b
Joined: 08 May 2008
Posts: 4
|
| Posted: Thu May 08, 2008 12:27 pm Post subject: |
|
|
| VinzC wrote: | Example:
| Code: | | <mount device="/dev/hda3" fs-type="ext3" options="defaults" ext3:errors="remount-ro" dump="0" pass="1">/var</mount> |
if you consider mount /var. It's just *one* example though. There are plenty of others. |
And now you have an extra layer of complexity: attributes and elements. Your example doesn't even describe what /var is. If you could stick to mere attributes, a miniscule amount of human-readability would be restored. But for structural data you need elements. Thus it's better stick to elements entirely, to keep things simple. But XML syntax for that isn't readable. It was designed for markup within data, hence the nested element syntax, but loses to LaTeX even there. It was not designed for simple configuration files with most of the data being the structure itself.
This still works:
| Code: |
<mount
device = "/dev/hda1"
point = "/"
type = "ext3"
errors = "remount-ro"
dump = 0
pass = 1
/>
|
(note the slash)
But when you start nesting stuff, it gets awful. Consider e.g. support for auto-mounting any of a number of listed devices.
| Code: |
<mount
point="/usb"
>
<device
dev="/dev/usb1"
/>
<device
dev="/dev/usb2"
/>
</mount>
|
Or so. It gets really messy and complex with attributes and elements of a tag not being contained within the same "block" (ending/closing markers). Sure, this example could be improved by arbitrarily choosing between elements/attributes for each setting, but I think that's not the way to do it. One should stick to a consistent choice: either all elements, or simple settings attributes, and nested structural settings as elements. In both cases XML fails.
In .INI-style syntax, with .device being shorthand for mount.device. (Of course, one could also use indentation to mark nested structures, and the braced formats also handle them a bit better, although are otherwise heavier.)
| Code: |
[mount]
point="/usb"
[.device]
dev=/dev/usb1
[.device]
dev=/dev/usb2
|
|
|
| Back to top |
|
|
VinzC
Veteran
Joined: 17 Apr 2004
Posts: 2787
Location: Liège (Belgium)
|
| Posted: Thu May 08, 2008 3:25 pm Post subject: |
|
|
| VinzC wrote: | Example:
| Code: | | <mount device="/dev/hda3" fs-type="ext3" options="defaults" ext3:errors="remount-ro" dump="0" pass="1">/var</mount> |
if you consider mount /var. It's just *one* example though. There are plenty of others. |
| evvk wrote: | | And now you have an extra layer of complexity: attributes and elements. Your example doesn't even describe what /var is. If you could stick to mere attributes, ... |
That's why I wrote right below the example: It's just *one* example though. There are plenty of others. You gave another one. I didn't pretend my example was *the* best one; it was just one example amongst others.
The purpose here is not to discuss how and why the article "XML sucks". I gave *one* example to counter his argumentation and we both agree on my point since you're giving another example that proves better readability than the article's example.
| evvk wrote: | | If you could stick to mere attributes, a miniscule amount of human-readability would be restored. But for structural data you need elements. Thus it's better stick to elements entirely, to keep things simple |
I only partly agree with you. Stricto senso, attributes denote metadata. Semantically the data is /var if you consider the instruction mount /var. Hence <mount>/var</mount> in XML. The attributes aren't part of the data nor the data itself, they describe the data, especially the filesystem on the device.
Now, as you perfectly expressed, mixing elements and attributes makes the example less readable. However it's still much more readable than the article's example, which is what I wanted to demonstrate in the first place.
XML X stands for extensible, which means you can extend the definition of an element by adding variable content to a container. In my example, note the presence of namespace prefix ext3, which denotes a variable content container that is extended with attributes from a namespace of which ext3 is the prefix - agreed, I didn't give the schema. Given what you wrote, adding namespaces doesn't preach for readability if you're not familiar with XML and XML schemas, I agree .
I agree on the all-attributes only because it's really simpler to read and understand. In fact it's the best reduction of a conceptual model to provide the non-xml-geek with. Anyways both our argumentation tend to demonstrate my initial points: there are good and bad practices and the article's example illustrates the bad ones, IMHO.
| evvk wrote: | | One should stick to a consistent choice: either all elements, or simple settings attributes, and nested structural settings as elements. |
I don't agree. Using elements, attributes or mixing both first depends on what you need to model. Attributes typically represent metadata and the element the data. Only elements can materialize hierarchical content. Like databases you might want to simplify or denormalize a conceptual model, e.g. by using only attributes in the case of mapping /etc/fstab into XML. Attributes-only are more human-readable.
Using element-only should be reserved to data structures that have no metadata (or properties). Mapping properties into elements generally is a mistake but it depends on the final purpose.
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
Linux user #369763 |
|
| Back to top |
|
|
evvk
n00b
Joined: 08 May 2008
Posts: 4
|
| Posted: Thu May 08, 2008 4:49 pm Post subject: |
|
|
| Quote: |
I don't agree. Using elements, attributes or mixing both first depends on what you need to model. |
Much of the XML literature and fanboy talk is indeed full of semantic bullshit, metacrap even: overmodelling to the degree of unusability.
But in any case, for configuration files XML does not offer a good model, for reasons discussed below. For documents the model is more suited, but the syntax still crap.
| VinzC wrote: | | Using element-only should be reserved to data structures that have no metadata (or properties). Mapping properties into elements generally is a mistake but it depends on the final purpose. |
Configuration files are essentially all data, and the data is in the structure. The separation of data-elements and metadata-attributes seldom really applies. The XML approach of having the a special node in the tree structure for the "contents" of an element -- which is a stream of text and elements -- and other nodes for its attributes, isnt' well suited for configuration data, which does not naturally have a distinguished text/element stream. It's unnecessary baggage that complicates matters.
| Code: | <section label="foo">bar</section>
|
or, much better,
| Code: | \section[label="foo"]{bar}
|
clearly has the label as metadata/attribute of an element. But such semantics are typically rather artificial in configuration files, where all of the data is really equally important. In a text document, even the tags are unimportant compared to the actual text, whereas in a configuration file, the tags would be the primary data.
| Quote: | | there are good and bad practices and the article's example illustrates the bad ones, IMHO. |
The article illustrates a consistent (and highly popular) approach. I prefer consistency over the complexity of overmodelling and deciding setting by setting, whether it is an element or an attribute, when there's really no such semantic to be found. Either it's a primitive setting (leafnode), or a structural setting (subtree), is more typical of configuration data. |
|
| Back to top |
|
|
VinzC
Veteran
Joined: 17 Apr 2004
Posts: 2787
Location: Liège (Belgium)
|
| Posted: Fri May 09, 2008 1:26 am Post subject: |
|
|
I've worked two years as an XML Expert (it was my function, it's not necessarily what I think I am) for EAN International and I was involved in ebXML workgroups. I've spent much time investigating XML (especially XML schema and instance documents) to get a more accurate idea. The one kind of literature I retained is that from Roger L. Costello on www.xfront.com, for example.
| evvk wrote: | | Much of the XML literature and fanboy talk is indeed full of semantic bullshit, metacrap even: overmodelling to the degree of unusability. |
I just wonder what kind of litterature I read to forge me an opinion on XML.  I also wonder what allows you to declare that. Don't see a personal attack, I'm astonished to read such negative opinion and such a generalization.
I'll post a more substantial reply a little bit later. I'd like to read the rest of your post more carefully.
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
Linux user #369763 |
|
| Back to top |
|
|
VinzC
Veteran
Joined: 17 Apr 2004
Posts: 2787
Location: Liège (Belgium)
|
| Posted: Sun May 11, 2008 4:48 am Post subject: |
|
|
| evvk wrote: | | Configuration files are essentially all data, and the data is in the structure. The separation of data-elements and metadata-attributes seldom really applies. The XML approach of having the a special node in the tree structure for the "contents" of an element -- which is a stream of text and elements -- and other nodes for its attributes, isnt' well suited for configuration data, which does not naturally have a distinguished text/element stream. It's unnecessary baggage that complicates matters. |
I'm not sure I understand 100% what you mean - tell me if I'm wrong. You seem to compare a C-like data structure with a complex XML element, right? In this case all members of a structure *are* the data, for which mixing attributes and elements is uselessly complicating things, is that your point?
My point differs because I see it from another angle. You could always give the container XML element the name of the structure:
| C struct: | | struct foo { ... }; |
| XML element: | | <foo> ... </foo> |
You have full freedom to determine what your XML modeling will look like. So if you take such kind of modeling, what could prevent you from using attributes instead of elements?
In fact, unlike what you said, the separation of data-elements and metadata-attributes *does* really apply. Fact is many development applications split structure data into XML elements. However, take MSADO recordset for example: recordset data are all attributes - I don't take this as a proof, just as an example.
In the case of /etc/fstab, what logic did I follow? When you mount something, just ask: mount <what> <where>. So the next question is: should I create an element <mount ...>what</mount> or <mount ...>where</mount>? I'll come back to that later on.
The rest, if you look carefully, has really nothing to do with <where> nor <what>. The filesystem type qualifies what's on the device, options can be arguments for the mount instruction...
After all, the configuration data - in the case of fstab - qualify the mount operation: what, where, options, pass, dump, errors... There are also options that depend on the filesystem to mount but they're all data about the main data, which is the mount point.
So, thinking a little more, you see the best suitable XML representation of a mount point is one single element with all attribute. Example:
| Code: | | <mount source="/dev/sda3" type="ext3" destination="/var" errors="remount-ro" pass="1" dump="0" /> |
This can be considered a mount point element that has no data only attributes. This representation does hurt nothing. It's consistent with the analysis that was made. It's a good approximation of something to be humanly readable. It can be indented without violating parsing rules:
| Code: | <mount
source = "/dev/hda1"
destination = "/"
type = "ext3"
errors = "remount-ro"
dump = 0
pass = 1
/> |
Another example:
| Code: | <mounts>
...
<ext3:mount source="/dev/sda3" destination="/var" errors="remount-ro" pass="1" dump="0" />
<smbfs:mount source="//server/share" destination="/destination1" credentials="/path/to/credentials" />
<nfs:mount source="server:/exported/directory" destination="/destination2" errors="remount-ro" />
...
<mounts> |
In this case namespaces would allow you to provide default attributes if non specified depending on the mount type (pass, dump, errors, whatever) hence reducing the average maximum length of a configuration line.
It's true that in general data order matters in configuration files. Spaces have their own meaning as well as the position. It's also true that an XML element like the above will have most of its common attributes reapeated in subsequent elements but with a little difference: order does *not* matter.
More important: an XML file can always be transformed into something else, including the original configuration text file! So if you want to provide an editor for configuration files, the XML file provides everything that is needed to provide the editor with labels and input areas.
Going even further, consider an instance XML document - hence conforming to a schema be relaxNG or XML schema. The schema contains everything that is needed to provide an interface for editing the XML configuration file, aka the instance document. Once you know the structure you know what to do with it (e.g. how to represent it) and what it must contain (e.g. how to validate it).
The question here is not about providing XML to just store configuration data but *use* XML to provide a consistent way to a) validate the data, b) provide order-independent placeholders, c) provide self-references for editors, d) labels for referencing data placeholders and e) transform the data to whatever format you like. XML is here a means to validate configuration data (against a schema) and transform (using XSLT), for instance into a flat configuration file that the system will use.
In this case, fstab in only a small example. But XML could apply to various other configuration parameters. Why?
You currently have many representations of configuration data. /etc/fstab, for instance, which uses position as a hidden, non-obvious data. You have ini-like configuration files (samba). You have shell-like configuration files (VAR=data), like many system configuration files. You have declaration-like configuration files, like the ones you find with LDAP... We could find many more examples, couldn't we? This is *not* consistent.
I agree XML might not be the best representation for harmonized, standard configuration syntax but it has the benefit to provide at least one way, that both the machine and the Human can understand. If you want, XML could even be used to *generate* configuration files for POSIX-compliant shells...
I'm not preaching for XML but for a standardization of configuration syntax. XML is one of the various possibilities. I personally only know XML as such because I don't know the others. Frankly the advantages of XML balance the disadvantages.
Now call me a heretic if you want...
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
Linux user #369763 |
|
| Back to top |
|
|
evvk
n00b
Joined: 08 May 2008
Posts: 4
|
| Posted: Sun May 11, 2008 11:12 am Post subject: |
|
|
| VinzC wrote: |
In fact, unlike what you said, the separation of data-elements and metadata-attributes *does* really apply. Fact is many development applications split structure data into XML elements. However, take MSADO recordset for example: recordset data are all attributes - I don't take this as a proof, just as an example. |
Which comes first? The chicken or the egg? Was the datastructure for the problem first found to be best modelled in XML, or did the hype-compliant decision to use XML come first, and then the data structure enforced into this model? The latter is more likely, given the XML silver bullet hype.
| Quote: | | More important: an XML file can always be transformed into something else, including the original configuration text file! So if you want to provide an editor for configuration files, the XML file provides everything that is needed to provide the editor with labels and input areas. |
As the article originally referred to says, there aren't good XML editors available. The text editors are the only semi-decent ones. But XML syntax seldom is human-readable.
| Quote: | Going even further, consider an instance XML document - hence conforming to a schema be relaxNG or XML schema.
The schema contains everything that is needed to provide an interface for editing the XML configuration file, aka the instance document.
|
You expect there to be a wide variety of editors, fit for everyone's user interface tastes, that provide support for such overcomplexity? When simply having a human-readable syntax would do. (Now recall my point about overmodelling...)
Last edited by evvk on Sun May 11, 2008 12:06 pm; edited 1 time in total |
|
| Back to top |
|
|
i92guboj
Moderator
Joined: 30 Nov 2004
Posts: 6327
Location: Córdoba (Spain)
|
|
| Back to top |
|
|
m1k0
Tux's lil' helper
Joined: 27 Dec 2006
Posts: 91
|
| Posted: Sun May 11, 2008 12:54 pm Post subject: |
|
|
Wow! XML (with XML Schema) config files is a great idea!
XML is a right way.
I thing, that would be great to have one XML Schema for every Linux distro.
For embedded environment we can use WBXML.
--
Java developer
_________________
http://mobiKAR.net - mobile KARAOKE |
|
| Back to top |
|
|
AllenJB
l33t
Joined: 02 Sep 2005
Posts: 729
Location: Southampton, Hampshire
|
| Posted: Sun May 11, 2008 1:05 pm Post subject: |
|
|
POSIX shell code vs XML.
POSIX shell code is:
* Highly intiutive - Sysadmins have been using for decades. Doesn't require any skills beyond shell script, which most Gentoo users would aquire over time anyway if they don't have them from other linux distros
* Extremely well specified and documented - lots of good guides available already.
* Clear definition between single and double quotes
* Decoding is easier than XML because the shell already does it
* Requires no extra code above what's already there
* Easily readable (compare the fstab XML example above to a real fstab - I know which I prefer, and it doesn't involve angle brackets everywhere)
* Doesn't require rewriting or patching existing tools (I haven't looked at openrc yet, but I bet a lot of what it does is actually done by other tools already in the *nix/POSIX tool set)
* Others I didn't think of yet...
_________________
My ebuilds: http://allenjb.me.uk/ (UT2k4 Map Packs, Nostromo N50, Uplink, Patched asus_acpi & madwifi-ng for Eee PC - see also atl2 for the EeePC) |
|
| Back to top |
|
|
Naib
Veteran
Joined: 21 May 2004
Posts: 2783
Location: UK - Birmingham
|
| Posted: Sun May 11, 2008 1:46 pm Post subject: |
|
|
| VinzC wrote: |
The example of a mount point is also not the best example one could have written:
| Code: | <mount>
<device>/dev/hda1</device>
<point>/</point>
<type>ext3</type>
<errors>remount-ro</errors>
<dump>0</dump>
<pass>1</pass>
</mount> |
|
And that is a perfect example of why XML for human editable config files is bad mmmmkay
its just sooo noisy. It is very hard to see where a tag end,a variable begins or an element could start
Yes XML is "human readable" simply because it is in ASCII and (can be) written in english. Yes a machine can parse an XML file to get the info out
but do you know what... it ain't optimal for humans or machines FACT! it is a tradeoff to produce a structure that a machine can step over if a complex tree is needed PLUS a format that *IF* a human had the unfortunate task of fingering it, it is possible
Whats best for machines? a nice binary format - nice for speed,compactness and well can encode some nice complex structures. can a human mentally decode that? can they fsck
Whats good for a human? a nice flat ASCII config file with a per-line option. can a machine decode that? sure but it isn't the fastest of formats and the complexity is limited
YES XML has its place and as a means for an application to store its gui-set config sure use XML, but for RC stuff where
1) a human MUST edit it
2) the complexity isn't that deep
wtf inflict such a sadistic writing style on users. It was XML-based config that made me go bollox to einit when it was announced. I tried it once (two releases ago) and damb the XML was just faaar to awkard to work around and for no reason for its use except for "because we can".
It didn't have to be XML-based BUT it is
*IF* openRC had one config file which governed everything as well as dependancy of services then YES XML would be perfect for it, but then again it wouldn't get used alot or chosen as a standard rc-system for gentoo. Proof needed.... is einit the prefered rc-system ?
_________________
pkgcore, The way portage should be managed
| Quote: | | There is a forgotten, nay almost forbidden word, which means more to me than any other. That word is ENGLAND |
Last edited by Naib on Sun May 11, 2008 2:29 pm; edited 1 time in total |
|
| Back to top |
|
|
i92guboj
Moderator
Joined: 30 Nov 2004
Posts: 6327
Location: Córdoba (Spain)
|
| Posted: Sun May 11, 2008 2:26 pm Post subject: |
|
|
I, for one, wouldn't like to see anything like this implemented.
There's absolutely no point in adding yet one more level of complexity to something that is, intrinsically, a simple thing. I am not an XML lover either, but I can see how it has some interesting uses (the Gentoo site and the Gentoo documentation are two good examples of the power of XML). It's a good thing, even if I don't like it so much. I can live with that. But, sincerely, I can't see the point in using XML for something like fstab, or conf.d/net
fstab is maybe the worst example. XML is not a good thing for databases, and, fstab, is basically a table. Anything else than it is now, will just be worse. That includes XML, of course.
These files should be kept as simple as possible, XML will just confuse the users, and will bring more troubles than advantages. I like when things are ordered and tidied, but XML in this case will just add noise to the files, and I see really no advantage on using it to parse configuration files.
Just my opinion, of course.
_________________
Formerly known as 6thpink.
Gentoo Handbook | My home |
|
| Back to top |
|
|
Kollin
Apprentice
Joined: 24 Feb 2006
Posts: 245
|
| Posted: Sun May 11, 2008 2:49 pm Post subject: |
|
|
What ever you do guys(programers and scripters) please keep it simple and understandable (even for non english fluent people).It would be very sad to see something like winblows registry implemented in the rc system (and get crippled after every update) 
_________________
"Dear Enemy: may the Lord hate you and all your kind, may you be turned orange in hue, and may your head fall off at an awkward moment."
"Linux is like a wigwam - no windows, no gates, apache inside..." |
|
| Back to top |
|
|
VinzC
Veteran
Joined: 17 Apr 2004
Posts: 2787
Location: Liège (Belgium)
|
| Posted: Sun May 11, 2008 6:56 pm Post subject: |
|
|
I appreciate such an enthusiasm. However let me refocus on a certain number of things.
First off I never intended to mean XML as a *replacement* for configuration files! If I had wanted to lose all credit, that's what I'd have said! Instead just XML as a *supplement* to either store configuration data or generate the initially well-known (legacy) configuration files.
| AllenJB wrote: | | Sysadmins have been using for decades. |
Well, then computers would still have ferrite cores memory, the United States would never have sent astronauts to the moon and Belgians a Dutch man to the Space Station... I'm afraid the well known sentence "Because we've been doing that [well] for years without a problem!" shall not be taken as a good reason for rejecting any kind of suggested evolution.
| AllenJB wrote: | | XML will just confuse the users, and will bring more troubles than advantages. |
Who could prove there would be a problem? Who took a trip to the future, went back and brought clues that there would be? Our job as contributors and developers and forum attendees is to let the message pass as well as we can, provide the best documentation so that there is no ambiguity, no doubt ever possible. There will be trouble with XML for configuration data if nothing is made to prevent that. There will be no trouble if we all manage so that there is none.
| Naib wrote: | | And that is a perfect example of why XML for human editable config files is bad mmmmkay |
You didn't seem to take care of the example I wrote later, which contained only attributes as well as the argumentation I made around it...
| Naib wrote: | | wtf inflict such a sadistic writing style on users. |
| i92guboj wrote: | | There's absolutely no point in adding yet one more level of complexity to something that is, intrinsically, a simple thing. |
| Naib wrote: | | its just sooo noisy. It is very hard to see where a tag end,a variable begins or an element could start |
Complexity... Difficulty... Not easy to follow or understand... Too much complexity for a simple task... Ok but you guys are forgetting that many of the Linux users have quit the over-simple world of [you know what I mean] for the steep learning curve of Linux! Goodness, I hardly believe this is now a matter of difficulty to have XML enter the so cuty Linux world... Please stop arguing about difficulty or whatever could go against users sensitivity or sensibility. Also arguing with bad XML to say XML is evil is nothing but shifty. Curiously enough, only one person argued upon the attributes-only example that I wrote about fstab.
| evvk wrote: | | As the article originally referred to says, there aren't good XML editors available. |
But we're not talking about XML editors here but *settings* editors. Don't think about using an XML editor when all we need is just a settings editor. There could always be ncurses-based or graphics ones. Like written in python, perl, QT, GTK settings editor. There's already one of these: gconf-editor. And people quite seem to accomodate with it, don't they?
| i92guboj wrote: | | XML will just confuse the users, and will bring more troubles than advantages. |
I've given detailed argumentation on how XML would enforce data integrity by validating configuration data before it's applied. I've also given examples where XML could serve as a support for transformation into legacy configuration files.
| evvk wrote: | | You expect there to be a wide variety of editors, fit for everyone's user interface tastes, that provide support for such overcomplexity? |
Overcomplexity? Let's extrapolate a little. XML schemas provide strong validation and can be used to enforce relationships between nodes. Currently syntax verification and validation *must* be done at the application's side, resulting in an equal overhead in every application that uses a given syntax. More syntaxes, more overhead.
Applications that are linked against XML verification libraries will hence be lighter. Validation code will then be shared. Besides providing shared data verification and validation, there would be just one library to manage/check/validate/input configuration data. Even further, why wouldn't such a library also provide ncurses- or graphics-based input forms?
There is more to XML than just a set of characters and tags.
| evvk wrote: | | Extremely well specified and documented - lots of good guides available already. |
So let there be one more.
See Gnome: whether or not this is a problem to the community of users, it's there. And users are doing with it. See how many "tips and tricks about gconf editor" on the Internet. So it's not a question how difficult it'll be but our own will to see things change/evolve or not. If it's properly documented and designed, it has fewer chances to be rejected.
| Naib wrote: | | *IF* openRC had one config file which governed everything as well as dependancy of services then YES XML would be perfect for it, but then again it wouldn't get used alot or chosen as a standard rc-system for gentoo. Proof needed.... is einit the prefered rc-system ? |
The matter is not only about OpenRC - though a good place to start - but the whole point of application settings syntax. Please take no offense but one yet needs to agree there are [too many] various configuration syntaxes. There must be one parser for each, making the code heavier than strictly necessary. We need harmonization. Wether you agree or not, this is going to happen some day. I'm not focusing on XML in particular but it's the only language that *I* know of (because I don't know the others, pardon me if I'm paraphrasing myself) and that applies best. If you want to go JSON, for example, so please do, I'm really *not* obsessing upon XML and have absolutely *no* objection against anything else than XML.
One problem is if we go on sticking to POSIX-compliant syntax, the syntax conventions for constructing variable names *will* become ugly. It has already begun to be:
| Code: | | module_cx88_dvb_args_2_6_23_gentoo_r5="video_br=2" |
I can't decently understand anyone who claims *that* is easy to reproduce without confusion. I'm waiting for the first person who'll swap kernel version and "args" for instance. POSIX-compliant syntax has its limitations (e.g. no arrays, if I understood).
XML (or any kind of equivalent that would receive your vote) would for instance be implemented in parallel to the current state of configuration system. Example scenarios:- If the application is written to support XML config data, then it uses XML directly.
- If an appllication doesn't support XML configuration data then the XML config file is transformed using XSLT to create the legacy configuration file. Best is no XML config data, just the legacy file.
Of course, I never suggested to throw in XML without further notice - again, should I have wanted to lose credits, that's what I'd have said!
Providing XML for configuration data must be intended for a large scale project, building the libraries, validation code and input forms first. Properly documented, developers should have no big troubles elaborating a schema with data validation rules - if ever they need some. This can range from the simplest atom types (string, integer, float, boolean, aso, which are trivial for validation since directly validated using a schema), to more complex rules (value A positive if value C equals "this string").
Given the degree of freedom of this system, it can of course be implemented in parallel with current configuration styles - hence I never talked about replacing the current state of configuration syntaxes. A progressive transition can be made. Whoever wants to take part in it has the opportunity to do it whenever he/she wants to.
Another direction?
Ok. Talking about API's, there should be no reason to force developers to know how to construct XML configuration files directly. I haven't taken a look at how Gnome's gconf-editor is made but I'm sure it has the proper API's to put/get configuration data without having to write to the XML file directly. Besides, in the case of dependency rules between data nodes, some API's should also be created. And these rules coud be - why not - stored as XML...
Things don't need to be complex at first. Data and Rules API's might be simple and based on what exists in gconf-editor. The advantage is that code already exists, can be enhanced and extended. Only the [input] interfaces currently lack - ncurses- and graphics-based. Most of all, configuration data being XML manual editong is still possible.
Care should of course be taken not to use the worst possible representations, as previously discussed.
And in this case, yes, XML would be a replacement for legacy configuration files. But with some support from API's. I've been thinking over and over while writing this post. Took me hours to type so please, take your time to reply .
I doubt everything I discussed here in this post deserves to be thrown away... 
_________________
Gentoo addict: tomorrow I quit, I promise!... Just one more emerge...
Linux user #369763 |
|
| Back to top |
|
|
Sparky Bluefang
n00b
Joined: 05 Jan 2008
Posts: 7
Location: Vermont, USA
|
| Posted: Sun May 11, 2008 10:29 pm Post subject: |
|
|
I think this discussion s pretty moot. Systems like OpenRC will never implement it because they don't want/can't have the dependencies. And your idea of side-by-side config files would just end up being much more confusing and adding much unneeded complexity. Plus, you are forgetting that to have it side-by-side, you still have the compile/run time dependencies of he XML library, even if you aren't using it.
XML dose have its uses. It's great for representing documents (DOM) and hierarchical data. But it is horrible for tables and large amounts of data. there is a degree of overhead with the XML structure and it can easily get extremely messy.
I also do not know where people get off on saying that it's "human readable". They've evidently never dealt with extremely large amounts of data or data in tables. In fact, I'm currently employed by IBM to develop and write software so they don't have to deal with XML by hand because it is a nightmare when you have a 150 X 150 table of characters representing wafer/chip locations and you have to change one character in that table to deselect a chip (along with pushing that data, and more, back a forth between various formats).
Config files are neither documents or (generally) hierarchical data, so I don't see how XML can do anything other than get in the way of the actual data. |
|
| Back to top |
|
|
evvk
n00b
Joined: 08 May 2008
Posts: 4
|
| Posted: Mon May 12, 2008 12:40 am Post subject: |
|
|
| VinzC wrote: | | evvk wrote: | | As the article originally referred to says, there aren't good XML editors available. |
But we're not talking about XML editors here but *settings* editors. Don't think about using an XML editor when all we need is just a settings editor. There could always be ncurses-based or graphics ones. Like written in python, perl, QT, GTK settings editor.
|
Given the levels of complexity you suggest, with doing schemas and shit, it's highly unlikely that there will be much, if any, choice. More likely, there will be just a few WIMP editors written by paid developers. Those who prefer decent ncurses apps don't get paid, and don't have the time. (Indeed, the paid developers are adding complexity over complexity all the time all over linux, making it all the time more difficult to write alternatives to their software. This gives them power and helps to keep their job.)
| Quote: |
There's already one of these: gconf-editor. And people quite seem to accomodate with it, don't they? |
Wow, one piece of the kind of crap I mentinoed.
| Quote: | | Currently syntax verification and validation *must* be done at the application's side, resulting in an equal overhead in every application that uses a given syntax. |
Now you're only arguing for using a library for reading a semi-standard configuration file format, instead of a proprietary one (which the article referred to also argues for).
Editors needing schemes to repre | | |
Gentoo Chat
