LINUX.ORG.RU
ФорумTalks

Соц. опрос: Формат конфигов


0

0

Собственно интересует какой формат конфигов предпочитают больше:

1) "классический" - что то вида
DAEMON_UID=nobody
DAEMON_GID=nogroup
SERVICE_BLA_INTERFACE=eth0
SERVICE_BLA_PORT=37143
SERVICE_BLA_DEFACLACTION=deny
SERVICE_BLA_ALLOW=bla; blabla
SERVICE_BLA_DENY=bla; blabla
blablabla...
...

2) XML - что то типа того
<config>
<daemon uid="nobody" gid="nogroup"/>
<service name="bla" iface="eth0" port="37143">
<acl default="deny">
<allow host="bla"/>
<allow host="blabla"/>
<deny host="bla"/>
<deny host="blabla"/>
</acl>
</service>
blablabla...
...
</config>

3) другой (привести пример)

★★

1) для всего, кроме
2) для программ, которые сами _записывают_ свой конфиг. Ибо им легче.
3) ну и m4 для ужоснаха.

Zulu ★★☆☆
()
Ответ на: комментарий от klalafuda

Потому что если для конфигурации openbox есть гуевый костыль, то для ivman его нет, а штука уж больно полезная.

grob ★★★★★
()
Ответ на: комментарий от suser

быдломище-то и невдомек, что это ниразу не похоже на быдлолисп и уж тем более на быдлохаскель

anonymous
()
Ответ на: комментарий от lg

Это ещё ничего, жаль вы не видели моего кода на С...

bugmaker ★★★★☆
()

С точки зрения ручного ковыряния. В первом случае что сразу бросается в глаза? Правильно, имена параметров. А во втором? Правильно, теги и скобочки. Я ответил на вопрос? :)

yozhhh ★★★
()
Ответ на: комментарий от yozhhh

> Почему? А если interoperability никуда не упёрлась и не упрётся?

XML - это стандарт, причем более чем распространенный. этого вполне достаточно, чтобы не рассматривать наколеночные поделки как класс. пусть даже самые красивые и пушистые.

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от yozhhh

> Почему? А если interoperability никуда не упёрлась и не упрётся?

..а если interoperability никуда не уперласть и не упрется, что конечно же очень и очень странно для минимально приличного продукта, занимайтесь сами таким "проектом" и используйте что хотите. ведь все равно они никому и никуда не уперлось, правда?

// wbr

klalafuda ★☆☆
()

1) key: value - как-то попроще воспринимаются...

bsh ★★★
()
Ответ на: комментарий от Pi

> http://www.pault.com/pault/pxml/xmlalternatives.html

прелестный набор ссылок, спасибо. врать не буду, я не просмотрел и пятой части. но у меня есть смутное подозрение, что ни одна из ссылок не ведет ни на www.w3c.org, ни на www.omg.org ни в другие аналогичные места. как следствие: при прочих равных должна быть очень серезная причина выбрать любую из них в противовес XML.

ps: судя по всему, у нас просто разные подходы.

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

я просто к тому, что если "xml - стандарт", то это не значит, что стандарт для всего. кое-где без него сложно, действительно, но я против использования ксмл в роли затычки.

Pi ★★★★★
()
Ответ на: комментарий от Pi

> я просто к тому, что если "xml - стандарт", то это не значит, что стандарт для всего. кое-где без него сложно, действительно, но я против использования ксмл в роли затычки.

как кто-то уже обмолвился выше,

---cut---
по возможности XML, хотя в принципе сильно зависит от конфига.
---cut---

so как универсальное средство на все случаи жизни я его и не позиционирую. хотя если говорить о настройках, в рамки XML замечательно ложились [или легли бы] практически все, что мне приходилось реализовывать или разбирать.

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

никаких притензий не имею и лечить не буду - уловил что к чему в твоей позиции - я "не флейма ради" :)

Pi ★★★★★
()

1. + lisp + yaml в зависимости от ситуации.

CrazyPit ★★★
()
Ответ на: комментарий от klalafuda

> вы придуриваетесь или серьезно спрашиваете?

конечно, серьезно.

вы выдвинули агрумент в пользу использования xml, что синтаксис его стандартизован. но ведь стандарты есть и на m4 и на lisp. я думаю, что при желании и на виндовые ini-style конфиги некий стандарт найти можно.

но при этом xml менее удобочитаем, что остальные.

ananas ★★★★★
()
Ответ на: комментарий от ananas

> вы выдвинули агрумент в пользу использования xml, что синтаксис его стандартизован. но ведь стандарты есть и на m4 и на lisp.

второй пункт в аргументе было распространенность + поддержка со стороны огромного количества самых разных party, стандартные API доступа DOM/SAX etc. боюсь, что даже по такому простому но важному пункту ни lisp ни m4 не идут ни в какое сравнение с XML.

> я думаю, что при желании и на виндовые ini-style конфиги некий стандарт найти можно.

думаю, в том или ином виде можно, хотя скорее "общее описание как это видит контора XYZ a'la M$ в конкретный момент времени". и когда жизнь заставляет и ими пользуюсь [бывает иногда] благо простенький парсер этого дела занимает строк ~70 на C++ и пишется на коленке включая комментарии - куда уж проще.. но это крайний и кривой случай. конечно, уверен, можно найти не один десяток библиотек, который разбирают те-же .ini, каждая со своим, конечно правильным, API и тд. радость еще та.

сравнивать XML и .ini все-таки несколько странно, бо это мягко говоря разные весовые категории. представить в том-же .ini трех-четырех уровневое дерево да еще чтобы это было читабельно а тем более легко можно было править оч затруднительно. в виде XML легче простого.

> но при этом xml менее удобочитаем, что остальные.

IMHO очень спорное суждение. субъективное. я, допустим, совершенно спокойно "читаю" и редактирую XML, что само собой то-же субъективно.

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

> второй пункт в аргументе было распространенность + поддержка со стороны огромного количества самых разных party, стандартные API доступа DOM/SAX etc. боюсь, что даже по такому простому но важному пункту ни lisp ни m4 не идут ни в какое сравнение с XML.

не забывайте, что мы говорим про конфиги. тут распространенность xml сравнима с тем же лиспом. для каких-нибудь описателей интерфейса типа glade или простеньких датабаз xml подходит. потому что с ним будет работать в основном программа. а конфиги приходится ровнять человеку. и тут успользование xml будет усложнением. имхо неоправданым

> сравнивать XML и .ini все-таки несколько странно, бо это мягко говоря разные весовые категории. представить в том-же .ini трех-четырех уровневое дерево да еще чтобы это было читабельно а тем более легко можно было править оч затруднительно. в виде XML легче простого.

насчет разных весовых согласен. но изначально не была указана сложность конфигов. для простенького конфига с десятком key-value пар ini-style или вообще чего самопридуманого будет вполне достаточно. xml тут явный оверхед.

если конфиг и большой и развесистый, то конечно, надо что-то более мощное. но и удобочитаемое. xml тут тоже не очень. имхо, более подходит что-то вроде апачевского конфига или иксового конфига.

а субективность... так практически все высказывания в подобных флеймах субъективны. специфика...

ananas ★★★★★
()
Ответ на: комментарий от W98

>подскажет ли кстати кто-нибудь удобную либу для работу с конфигами 1-го вида? типа как в оффтопике GetPrivateProfileString() GetPrivateProfileInt() итд

я пользовал regex. Мне понравилось

cvv ★★★★★
()
Ответ на: комментарий от ananas

файлы настройки - это, как правило, лишь весьма небольшая хотя и достаточно важная часть системы XYZ. согласен, в каждом конкретном случае может быть *элегантней* использовать схему ABC. в принципе, зачем городить то-же дерево XML, когда можно сделать или проще или удобнее но частное решение?

однако, IMHO есть один золотой принцип: правило наименьшего удивления. когда действие со стороны исполнителя должно вызывать наименьшее удивлениее со стороны заказчика. буквальное определение я не помню, оно было достаточно элегантным, но суть идеи сохранена.

лично я смотрю на задачу с точки зрения framework-а или хотя бы toolkit-а i.e. общее решение достаочно сложное задачи ABC для широкого круга потребителей. в этом случае, принцип наименьшего удивления очень даже применим бо потребители разные и всем не угодишь -> компромис решений наше все. как практическое следствие, чем более узнаваемые aka стандартные и распространенные идиомы мы применяем при разработке системы, тем проще людям в большинстве своем будет в это дело хотя бы вникнуть [а скорее всего и использовать]. и в такой ситуации, при наличии альтернативы между немного более хитрым но крутым и простым, но пусть менее эффективным решениями, выбор очевиден: открытый *и* распространенный *стандарт*, пусть даже менее эффективный, побеждает сиюминутные полеты фантазии.

так получилось, что ATM эту нишу занимает скорее XML, чем приведенные lisp/m4/ini/etc вместе взятые. ok, без вопросов и пусть это будет XML. у него со временем приросло масса плюсов. IMHO главное хоть на чем-то зафиксироваться более-менее подходящем и далее заниматья уже непосредственно своей задачей, а не долгим и мучительным выбором одного из тысячи но таки лучшего здесь и сейчас формата файла настроек.

ps: считайте это кратким изложением "идеологической базы" выбора. приняли бы в свое время другой формат межсистемного обмена данными - был бы другой и никто и не вспоминал бы об XML. бо счастье не в тегах, счастье во взаимном понимании cторон.

// wbr

klalafuda ★☆☆
()
Ответ на: комментарий от klalafuda

>есть один золотой принцип: правило наименьшего удивления

Как потребитель софтовой продукции, заявляю: у меня вызывает удивление слова "конфиг в XML-подобном формате". Причём количество вызваного удивления вызывает навязчивое желание найти альтернативный продукт.

Таков вот мой личный опыт;-)

DonkeyHot ★★★★★
()
Ответ на: комментарий от DonkeyHot

>> Как потребитель софтовой продукции, заявляю: у меня вызывает удивление слова "конфиг в XML-подобном формате". Причём количество вызваного удивления вызывает навязчивое желание найти альтернативный продукт. Таков вот мой личный опыт;-)

по подробнее! сложность восприятия/правки|нелогичность, что именно?

Ex ★★
() автор топика
Ответ на: комментарий от Ex

сложность восприятия, много букф лишних печатать надо
XML - это не для того чтобы туды ручками лазить

W98
()

как насчет такого Cишного =]:

daemon {
 uid nobody;
 gid nogroup;
};

service bla {
 interface eth0;
 port 37143;
 acl {
   default allow;
   allow {
    bla;
    blabla;
   };
   deny {
    bla;
    blabla;
   };
 };
};
blabla...
...

Ex ★★
() автор топика
Ответ на: комментарий от Ex

тогда уж lua =]

daemon={
 uid="nobody",
 gid="nogroup"
}

service_bla={
 interface="eth0",
 port=37143,
 acl={
  default="allow",
  nondefault="deny"
 }
}

W98
()
Ответ на: комментарий от Ex

кстати очень даже натурально выглядит :)

Pi ★★★★★
()
Ответ на: комментарий от ananas

> стандарт для чего?

Последнее время это стандартная затычка, современная молодёжь пихает его всюду, куда не лень.

anonymous
()
Ответ на: комментарий от W98

>2 - удобнее для программистов, особенно если конфиги навороченные, с иерархией и их надо крутить по-всякому

Совершенно не согласен!
Разрабатывать прогу надо сразу под нормальный конфиг, а если конфиг шибко иерархичный - то нах!
К примеру: написал чело прогу под с конфигом XML - а я хочу сделать к ней конфигурялку или еще что.
так для моей проги тоже нужна либа XML-ная! А это как минимум 100Кил!
Про ембедед девайсы и дистрибутивы на дискетке тут же можно забыть!

А если эта прога - какой-нибудь демон, а не десктопная тулза?

Да и все программы, писанные веками (grep, awk, sed) можно выкинуть сразу на помойку!

ИМХО: НАХ эти виндовозные поделки! XML разрабатывался для хранения документов - вот пусть и дальше так будет! Так бля до реестра-виндовс докатимся!

Ant0
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.