On 11/17/05, Gilboa Davara <gilboada@xxxxxxxxxxxxxxxx> wrote: Agreed on A+B. C depends on implementation. There is some truth to D, but I suspect that many simple scripts make assumptions about the state of the file and can often fail (eg if the file is hand edited). There are many benefits: As mentioned earlier, handling international characters becomes transparent. Schemas can be used to perform validation. Manipulation by software is potentially much easier. If there is a standard schema for representing common elements such as users, permissions, access control lists etc then a standard library can be written to translate these objects into Python, Java or C++ objects and vice versa. I'm not necessarily advocating the use of XML. I think it is not practical to force people to use this (or any other) format if they do not want to. So instead of stick... some carrot :-) Pick two or three common formats. Define them precisely (make them an official standard -- like the Sun/Java JSR idea). Write an access library for the most popular application languages (C/C++, Python, Java etc) and include those libraries in the Core. In conjunction with this a "best practices" document can make recommendations on how to best implement configuration files (eg pointing out things which some people might forget: i18n issues, time/date issues, handling different config for different machine states / runlevels), and point out common mistakes. If you have time, please take a look at /etc/*.conf. Most files there key-value pairs grouped into sections. But almost every file has a slightly different syntax! Joe. > A. Hard to read. > B. Hard to edit using non-XML editors. (vim in my case) > C. Tends to create needlessly-complex data structures. > D. While can be accessed using shell scripts, it requires very complex > and unreadable code. > > On the other hand, what does XML offer in return? Quiet a lot if implemented properly. > > Gilboa > > > -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
