XML для конфигурационных файлов, почему? [закрытый]
Вы были абсолютно правы. Я отправлял одну и ту же трансляцию не раз. Я обнаружил это в беговой дорожке, предназначенной для затухания музыки.
9 ответов
Спасибо за ваши ответы. Этот вопрос, каким бы наивным он ни казался на первый взгляд, не был таким наивным:)
Лично мне не нравится XML для файлов конфигурации, я думаю, что людям трудно читать и изменять, и компьютерам трудно разбирать потому что он такой общий и мощный.
INI-файлы или файлы свойств Java подходят только для самых простых приложений, которые требуют вложенности. Общие решения для добавления вложенности в эти форматы выглядят следующим образом:
level1.key1=value
level1.key2=value
level2.key1=value
не очень привлекательное зрелище, много избыточности и трудно перемещать объекты между узлами.
JSON - не плохой язык, но он разработан так, чтобы компьютерам было легко синтаксический анализ (это допустимый JavaScript), поэтому он не используется для файлов конфигурации.
JSON выглядит следующим образом:
{"menu": {
"id": "file",
"value": "File",
"popup": {
"menuitem": [
{"value": "New", "onclick": "CreateNewDoc()"},
{"value": "Open", "onclick": "OpenDoc()"},
{"value": "Close", "onclick": "CloseDoc()"}
]
}
}}
На мой взгляд, он слишком загроможден запятыми и кавычками.
YAML хорошо для файлов конфигурации, вот пример:
invoice: 34843
date : 2001-01-23
bill-to: &id001
given : Chris
family : Dumars
однако, мне не очень нравится его синтаксис, и я думаю, что использование пробелов для определения областей делает вещи немного хрупкими (подумайте, вставив блок на другой уровень вложенности ).
Несколько дней назад я начал писать свой собственный язык для файла конфигурации, я назвал его Swush .
Вот несколько примеров: как простые пары ключ-значение:
key:value
key:value2
key1:value3
или как более сложный и прокомментированный
server{
connector{
protocol : http // HTTP or BlahTP
port : 8080 # server port
host : localhost /* server host name*/
}
log{
output{
file : /var/log/server.log
format : %t%s
}
}
}
Swush поддерживает строки в простой форме выше или в кавычках - что позволяет использовать пробелы и даже переводы строк внутри строк. Я собираюсь добавить массивы в ближайшее время, что-то вроде:
name [1 2 b c "Delta force"]
Существует реализация Java, но приветствуются другие реализации. :). проверьте сайт для получения дополнительной информации (я рассмотрел большую часть этого, но Java API предоставляет несколько интересных функций, таких как селекторы)
This is an important question.
Most alternatives (JSON, YAML, INI files) are easier to parse than XML.
Also, in languages like Python -- where everything is source -- it's easier to simply put your configuration in a clearly-labeled Python module.
Yet, some people will say that XML has some advantage over JSON or Python.
What's important about XML is that the "universality" of XML syntax doesn't really apply much when writing a configuration file that's specific to an application. Since portability of a configuration file doesn't matter, some Python folks write their configuration files in Python.
Edit
Security of a configuration file does not matter. The "configuring a Python program in Python is a security risk" argument seems to ignore the fact that Python is already installed and running as source. Why work up a complex hack in a configuration file when you have the source? Just hack the source.
I've heard folks say that "someone" could hack your app via the configuration file. Who's this "someone"? The sysadmin? The DBA? The developer? There aren't a lot of mysterious "someone"s with access to the configuration files.
And anyone who could hack up the Python configuration file for nefarious purposes could probably install keyloggers, fake certificates or other more serious threats.
- XML is easy to parse. There are several popular, lightweight, featureful, and/or free XML parsing libraries avaliable in most languages.
- XML is easy to read. It is a very human-readable markup language, so it's easy for humans to write as well as for computers to write.
- XML is well specified. Everyone and his dog knows how to write decent XML, so there's no confusion about the syntax.
- XML is popular. Somewhere along the way, some Important People™ started pushing the idea that XML was the "future", and a lot of people bought it.
- XML is a bidirectional format. That is whitespace, comments, and order are preserved. You can programmatically load, change and then save it while preserving the formatting. This is important for tools that users can use to configure their applications. It is one of the reasons XML originally took off (the world has become more technical so this is less of a need).
- XML has optional schema validation. Important for tools and complex configuration formats.
- XML has namespaces. This allows other configurations or annotations to be embedded with out effecting the parsing. In other configuration formats this is usually done as a with hack special comments or property name mangling.
As a side note, I'm not trying to defend XML. It has its uses, and I will be using it in a project whenever I get back to that. In many cases, though, and especially configuration files, the only advantage it has is that it's a standardized format, and I think this is far outweighed by numerous disadvantages (i.e. it's too verbose). However, my personal preferences don't matter - I was merely answering why some people might choose to use XML as a configuration file format. I personally never will.
Поскольку XML звучит круто и предприимчиво.
Редактировать: я не понимал, что мой ответ был настолько расплывчатым, пока комментатор не запросил определение enterprisey . Ссылаясь на Википедию :
[...] термин «предприятие» предназначен для того, чтобы выйти за рамки «избыточного количества ресурсов для небольших организаций», подразумевая, что программное обеспечение является слишком сложным даже для крупных организаций, и доступны более простые, проверенные решения.
Я хочу сказать, что XML - это модное слово, и поэтому его злоупотребляют. Несмотря на другие мнения, XML не так просто разобрать (просто посмотрите на libxml2, его исходный пакет gzipped в настоящее время занимает более 3 МБ). Из-за количества избыточности это также раздражает писать вручную. Например, Википедия перечисляет конфигурацию XML в качестве одной из причин снижения популярности jabberd в пользу других реализаций.
XML - это хорошо разработанный и принятый стандарт, облегчающий чтение и понимание, чем проприетарные форматы конфигурации.
Кроме того, стоит понимать, что сериализация XML - это распространенный инструмент, доступный на большинстве языков, который делает сохранение данных объекта чрезвычайно простым для разработчиков. Зачем создавать свой собственный способ сохранения иерархии сложных данных, когда кто-то другой уже сделал эту работу за вас?
.NET: http://msdn.microsoft.com/en-us/library/system.xml.serialization.aspx
PHP: http://us.php.net/serialize
Python: http://docs.python.org/library/pickle.html
Java: http://java.sun.com/developer/technicalArticles/Programming/serialization/
Еще один момент: если у вас есть XSD (файл схемы) для описания вашего файла конфигурации, ваше приложение тривиально проверяет файл конфигурации.
Поскольку синтаксический анализ XML относительно прост, и если ваша схема четко указана, любая Утилита может легко читать и записывать информацию.
Well.., XML is a general-purpose specification that can hold descriptions, nested information and data about something. And there are many APIs and softwares that can parse it and read it.
So it's much easy to describe something in formal way that is known cross platforms and applications.
Its because XML allows you to basically make your own semantic markup, which can be read by a parser built in virtually any language. An added benefit is that the configuration file written in XML can be used on projects where you are using two or more languages. IF you were to make a configuration file where everything was defined as variables for a specific language, it would only work in that language, obviously.