Компании Canonical, Cisco, IBM, Intel, NetApp, Red Hat и SUSE объявили (http://www.redhat.com/about/news/prarchive/2011/Open-Virtual...) об объединении усилий в плане продвижения и разработки открытого проекта oVirt (http://www.ovirt.org/), в рамках которого развиваются технологии по обеспечению управления системами виртуализации. Совместными усилиями компании планируют сформировать новое сообщество разработчиков, нацеленное на разработку открытой платформы виртуализации, включая создание новых инструментов для управления гипервизором KVM.Компания Red Hat открыла в рамках проекта oVirt технологии управления системами виртуализации, используемые в продукте Red Hat Enterprise Virtualization (https://www.opennet.ru/opennews/art.shtml?num=32341), включая гипервизор KVM, средства для запуска и развёртывания виртуальных машин, сопутствующие инструменты и библиотеки, такие как libvirt и v2v. Целью oVirt является созд...
URL: http://www.redhat.com/about/news/prarchive/2011/Open-Virtual...
Новость: https://www.opennet.ru/opennews/art.shtml?num=32568
Хватит уже XML втюхивать повсюду в конфигах!
Хватит его уже всюду втюхивать. Пора признать, что концепция тухлая и облажалась повсюду.
ваш вариант?
[secction_name]
parameter=value
> [secction_name]
> parameter=valueа теперь впихиваем сюда многоуровневое описание объекта
> а теперь впихиваем сюда многоуровневое описание объектаКонфиг апача и nginx.
А если надо вложить секцию в секцию?
Смотри ~/.fluxbox/menu
ИМХО, самый нормальный: http://search.cpan.org/dist/Config-General/
Самый поддерживаемый: http://search.cpan.org/dist/JSON/
Альтернативный вариант (надмножество JSON): http://search.cpan.org/dist/YAML/Так что вариантов предостаточно.
> ИМХО, самый нормальный: http://search.cpan.org/dist/Config-General/
> Самый поддерживаемый: http://search.cpan.org/dist/JSON/
> Альтернативный вариант (надмножество JSON): http://search.cpan.org/dist/YAML/JSON не содержит business critical features как XSD и namespaces.
Остальные из вашего списка вроде тоже. Так что выбор есть, но его увы нет.
XML - в большинстве своем не оптимальный формат, но более подходящего для массового применения не сделано.
PS если бы все конфиги были на XML, то можно было бы сделать ОДИН универсальный конфигуратор работающий по XSD схемам. пока же в пингвине каждый конфиг - отдельная хрень не поддающаяся стандартизации.
> business critical features как XSD и namespacesТы хоть сам понял что сказа то?
> XML - в большинстве своем не оптимальный формат
зачем тогда его втюхивать если под каждую задачу есть свои оптимальные форматы. Практика показывает что со временем все равно все сводится к 2-3 языкам/вариантам написания конфигов. Это осилит любой админ.
> PS если бы все конфиги были на XML, то можно было бы сделать ОДИН универсальный конфигуратор
идиалистический бред
Бинарные конфиги, генерируемые по текстовым.
+1Если хранить конфиги по фиксированному адресу непосредственно в исполняемом файле, то можно избежать лишних операций чтения с диска и добиться повышения произоводительности и уменьшения количества программного кода.
> избежать лишних операций чтения с диска и добиться повышения произоводительностиЧтение конфигов в общем случае происходит не настолько часто чтобы время этой операции роялило бы. В сильно некоторых случаях - может быть, но, извините, прямо в исполняемом файле - это изврат какой-то.
Бугага. И редактировать их в HEX-редакторе. И не дай бог лишний байт добавишь.
Правильно. И вообще - все программы должны быть статически скомпилированы с ядром системы.
ymlспециально для конфигов придумывался, очень удобен, лаконичен, компактен и ёмок
> yml
> специально для конфигов придумывался, очень удобен, лаконичен, компактен и ёмокЯзыки РАЗМЕТКИ не нужны для конфигов.
> Языки РАЗМЕТКИ не нужны для конфигов.Не судите о книге по обложке.
YAML Ain't Markup Language
> Языки РАЗМЕТКИ не нужны для конфигов.Это кто Вам такую глупость сказал?
Это не "лаконичен". Это "чемодан эзотерических возможностей". Лакончиен был бы слегка доработанный JSON (с поддержкой комментариев, необязательностью заключения ключей в кавычки и поддержкой trailing comma, и BSON или MessagePack как эффективный компилированный вариант
Вы будете удивлены, но YAML и есть слегка допиленный JSON.
А зачем нужен слегка допиленный при наличии обычного? У JSON есть в общем то 1 плюс: не очень геморроен в парсинге и много кем понимается. Но все-таки далеко не самый простой и быстрый в парсинге формат.
YAML хорош тем, что при его потрясающей гибкости и расширяемости, он может быть (и в большинстве случаев) краток как JSON. Если действительно интересно -- полистайте спецификацию, доступную по адресу http://www.yaml.org/spec/1.2/spec.html Там много примеров, что можно с ним сделать.
> YAML хорош тем, что при его потрясающей гибкости и расширяемости, он может
> быть (и в большинстве случаев) краток как JSON. Если действительно интересно
> -- полистайте спецификацию, доступную по адресу http://www.yaml.org/spec/1.2/spec.html
> Там много примеров, что можно с ним сделать.Что то не нашел в спеке как описывается схема документа на его же языке. типа XSD for XML.
Или я не увидел этого или YAML еще одно нишевое решение, которое не стоит применять для реальных систем.
На, утрись: http://rx.codesimply.com
> На, утрись: http://rx.codesimply.comЭтот полудохлый сайт от 2008 года (сейчас уже конец 2011 для тех, кто в анабиозе) что показывает?
Есть ли отраслевой стандарт на схемы YAML? выпущенный тем же сообществом или консорциумом, что и сам YAML? Если нет - чем тут утираться. Тут только остается поржать над предложением использовать YAML, ибо YAML не может похвастаться стандартом на схемоописание.
у нас в нескольких проектах к ТЗ прилагались XSD для описания тех данных, которые могут придти. YAML и JSON на текущий момент не подходят. YAML просто слился, JSON имеет другие задачи и для конфигурирования использовать его бессмысленно.
JSON, хоть он и хорош внутри приложения, но для замены XML не подходит.
Когда в качестве аргументов в пользу чего-либо называются слова "отраслевой" и "стандарт", я иногда задумываюсь, та ли это отрасль, и так ли хорош стандарт? Пример: SMTP - это стандарт для электронной почты в интернете. Есть другая отрасль с другим стандартом - корпоративные почтовые системы основываются на стандарте X.400.
> Когда в качестве аргументов в пользу чего-либо называются слова "отраслевой" и "стандарт",
> я иногда задумываюсь, та ли это отрасль, и так ли хорош
> стандарт? Пример: SMTP - это стандарт для электронной почты в интернете.
> Есть другая отрасль с другим стандартом - корпоративные почтовые системы основываются
> на стандарте X.400.XML не идеален. А SMTP совсем крив. Но если делаешь почтовый сервер сегодня, то придется реализовать SMTP иначе другие сервера тебя не поймут. с XML почти та же история.
PS а как с помощью Х.500 отправить почту на mail.ru или gmail.com? стандарт хорош когда им пользуются, а не просто конь-в-вакууме ;)
YAML
Чем он вам не нравиться?
Довольно таки мощный инструмент, неплохо читается, можно много мето информации впихнуть. Если конечно не через жопу сверстанный... конфиги на нем вполне нормальный вариант.
Тот же json сложно просматривать, зато его быстрее и легче парсить.
> Довольно таки мощный инструментТакой же как ассемблер. Можно сделать что угодно, только ни писать, не читать что-то серьёзное невозможно.
> неплохо читается
s/неплохо/вообще не/
> можно много мето информации впихнуть
мето. школо.
> мето. школо.Оно еще и "ться" и "тся" не умеет писать. День двоечников на опеннете.
Круглый год, если не заметили.
> Чем он вам не нравиться?избыточностью
> Чем он вам не нравиться?Пухлый. Хреновато читается. Для конфигов избыточен и не сильно удобен в редактировании двуногими.
почему?
Если система сложная и гибко конфигурируемая, то не имеет никакого значения, какой язык описания конфигурации используется. Это в любом случае будет уныло и не понятно...В XML хотя бы структура есть. При вменяемости разработчиков со временем структура станет более понятна и очевидно. А плоские конфиги а ля apache хороши для небольших систем. Хотел бы я посмотреть на конфиг того же FreeSwitch'а реализованный в таком стиле... Я бы удавился...
> Хватит уже XML втюхивать повсюду в конфигах!а придумали что то лучше? аналог XSD уже сделали или как INI конфиги, где конфиг есть, а валидной схемы для его проверки не придумали?
>абстрагирована от типа гипервизораЭто значит, что негр будет пахать (на KVM), а умники получать навар на проприетарном гипервизоре... Очень мило(((
в общем - предсказуемое желание. Я только удивлен что в комплекте фирмачей место для вмварь не нашлось.
у них свой, полностью закрытый стек.
>Я только удивлен что в комплекте фирмачей место для вмварь не нашлось.как и xen
В результате должен остаться один и пусть это будет горец, то есть KVM
Оно их не жмёт. Но libvirt, кстати, заявляет о поддержке вмварной "сферы".
> CLI-интерфейсВооот, это труЪ, это по-нашему.
То есть что делает приложение уже не важно. Главное в чем конфиги хранить.