Здравствуйте, Дарней, Вы писали:

АПВ>>На какую идею? На идею бинарного конфига? Это плохая идея. У нее нет эксплуатационных преимуществ, но у нее есть заметные эксплуатационные недостатки.

Д>Нет эксплуатационных преимуществ? Как насчет select * from parameters where value="foo" ? Только не рассказывай мне про grep — чтобы его использовать, нужно помнить внутреннюю структуру конфига (sic!), нужно думать про обработку специальных символов (всевозможные \\ и &) и разбиение длинных значений по строкам.

Круто, однако
Как двоичный формат, с SQL-подобными запросами, так value может содержать только "foo". А как текстовый конфиг, так там не только escaping, но еще и разбиение длинных значений по строкам. Да и когда мы SQL-подобный запрос в двоичном конфиге делаем нам, конечно, логическую стуктуру знать не нужно -- ведь там только value и все, никаких тебе user.bob.auth.password или group.admins.rights и в помине нет. Какие-то двойные стандарты получаются

Хотя использовать grep с XML -- это действительно тяжеловато, имхо. А вот C-подобный escaping, как правило, проблем не вызывает, поскольку префиксуется, обычно всего несколько символов (обратная косая, кавычки, иногда \n и \t). Зато в grep-е офигенные регулярные выражения задавать можно.

Здравствуйте, eao197, Вы писали:

E>Круто, однако
E>Как двоичный формат, с SQL-подобными запросами, так value может содержать только "foo". А как текстовый конфиг, так там не только escaping, но еще и разбиение длинных значений по строкам.

Ну это просто пример... лень было набирать Пусть это будет не foo, а например список всех расширений, которые зарегистрированы в конфиге MySQL. Ваши варианты? С помощью регулярных выражений и такой-то матери?

E>Да и когда мы SQL-подобный запрос в двоичном конфиге делаем нам, конечно, логическую стуктуру знать не нужно -- ведь там только value и все, никаких тебе user.bob.auth.password или group.admins.rights и в помине нет. Какие-то двойные стандарты получаются

наверно, я просто неточно сформулировал. Чтобы искать информацию в текстовом файле — нужно знать не только его логическую структуру, но и то, как она представлена в самом файле. Например, нужно знать, как помечаются секции, отдельные параметры внутри секций и т.п. Когда ты работаешь с базой данных, знания о внутреннем представлении данных тебе не нужны.

E>Зато в grep-е офигенные регулярные выражения задавать можно.

К сожалению, на грабли с их помощью тоже очень легко наступать. Не говоря уже об их write-only синтаксисе.

Здравствуйте, Дарней, Вы писали:

E>>Как двоичный формат, с SQL-подобными запросами, так value может содержать только "foo". А как текстовый конфиг, так там не только escaping, но еще и разбиение длинных значений по строкам.

Д>Ну это просто пример... лень было набирать Пусть это будет не foo, а например список всех расширений, которые зарегистрированы в конфиге MySQL. Ваши варианты? С помощью регулярных выражений и такой-то матери?

Сразу история вспоминается, с которой мне довелось столкнуться. Мои коллеги написали софт, который считывает свою конфигурацию из отдельной таблички в БД. Да там конфигурации всего-то одна строка с пятью или шестью столбцами. А запускалась софтина с параметрами подключения к БД в командной строке. И в один прекрасный день потребовалось один параметр в конфигурации поправить. Никого из разработчиков, как водится, под рукой нет. Только я случайно рядом оказался. И вот что обидно -- есть непосредственный доступ к машине на которой крутится софт и сервер БД. Но нет инструментов для того, чтобы в табличке SQL базы одно значение поправить. Ну то есть нет ни одной приблуды, в которой можно было бы update написать. Да еще машина была не в локалке. Матюгался я тогда изрядно. С тех пор к конфигурации в недоступных vi или far двоичных форматах отношусь крайне негативно. Просто потому, что когда жареный петух клевать начинает, нужных инструментов, как водится, под рукой не оказывается. А текстовый редактор -- он практически везде есть.

E>>Да и когда мы SQL-подобный запрос в двоичном конфиге делаем нам, конечно, логическую стуктуру знать не нужно -- ведь там только value и все, никаких тебе user.bob.auth.password или group.admins.rights и в помине нет. Какие-то двойные стандарты получаются

Д>наверно, я просто неточно сформулировал. Чтобы искать информацию в текстовом файле — нужно знать не только его логическую структуру, но и то, как она представлена в самом файле. Например, нужно знать, как помечаются секции, отдельные параметры внутри секций и т.п. Когда ты работаешь с базой данных, знания о внутреннем представлении данных тебе не нужны.

Т.е. тебе не нужно думать, что выражение "Bob's Blog" в конфиге записывается как Bob\'s Blog или Bob's Blog? Да такое есть.
Но ведь в РСУБД тебе нужно знать названия таблиц, столбцов, а в случае сложных данных -- еще и отношения между ними. Это ведь так же не слабое знание логической структуры.

E>>Зато в grep-е офигенные регулярные выражения задавать можно.

Д>К сожалению, на грабли с их помощью тоже очень легко наступать. Не говоря уже об их write-only синтаксисе.

Зато они хорошо сохраняются в .sh (.bat) файлах, а затем легко повторно используются. С sql-запросами, конечно, такое так же возможно. Но вот как быть с поиском по реестру, например?

Здравствуйте, eao197, Вы писали:

Здравствуйте, eao197, Вы писали:

E>Сразу история вспоминается, с которой мне довелось столкнуться. Мои коллеги написали софт, который считывает свою конфигурацию из отдельной таблички в БД. Да там конфигурации всего-то одна строка с пятью или шестью столбцами. А запускалась софтина с параметрами подключения к БД в командной строке. И в один прекрасный день потребовалось один параметр в конфигурации поправить. Никого из разработчиков, как водится, под рукой нет. Только я случайно рядом оказался. И вот что обидно -- есть непосредственный доступ к машине на которой крутится софт и сервер БД. Но нет инструментов для того, чтобы в табличке SQL базы одно значение поправить. Ну то есть нет ни одной приблуды, в которой можно было бы update написать. Да еще машина была не в локалке. Матюгался я тогда изрядно. С тех пор к конфигурации в недоступных vi или far двоичных форматах отношусь крайне негативно. Просто потому, что когда жареный петух клевать начинает, нужных инструментов, как водится, под рукой не оказывается. А текстовый редактор -- он практически везде есть.

Ну это опять же вопрос доступности инструментов. А если стандартизовать единый формат для бинарных конфигов и в каждом дистрибутиве будет удобный редактор/навигатор по нему?

E>Т.е. тебе не нужно думать, что выражение "Bob's Blog" в конфиге записывается как Bob\'s Blog или Bob's Blog? Да такое есть.

Нет, я не совсем это имел в виду. Логическая организация файла — это когда нужно думать, что нужные тебе данные в конфиге могут выглядеть как variable=value, <variable>value</variable>, variable:value, variable!value или как-то еще.
К твоей задаче (найти нужную переменную) это на самом деле не имеет отношения — просто ненужная добавочная нагрузка.

E>Но вот как быть с поиском по реестру, например?

Не совсем понял, что ты имеешь в виду.

Здравствуйте, eao197, Вы писали:

Здравствуйте, eao197, Вы писали:

E>Сразу история вспоминается, с которой мне довелось столкнуться. Мои коллеги написали софт, который считывает свою конфигурацию из отдельной таблички в БД. Да там конфигурации всего-то одна строка с пятью или шестью столбцами. А запускалась софтина с параметрами подключения к БД в командной строке. И в один прекрасный день потребовалось один параметр в конфигурации поправить. Никого из разработчиков, как водится, под рукой нет. Только я случайно рядом оказался. И вот что обидно -- есть непосредственный доступ к машине на которой крутится софт и сервер БД. Но нет инструментов для того, чтобы в табличке SQL базы одно значение поправить. Ну то есть нет ни одной приблуды, в которой можно было бы update написать. Да еще машина была не в локалке. Матюгался я тогда изрядно. С тех пор к конфигурации в недоступных vi или far двоичных форматах отношусь крайне негативно. Просто потому, что когда жареный петух клевать начинает, нужных инструментов, как водится, под рукой не оказывается. А текстовый редактор -- он практически везде есть.

Ну это опять же вопрос доступности инструментов. А если стандартизовать единый формат для бинарных конфигов и в каждом дистрибутиве будет удобный редактор/навигатор по нему?

E>Т.е. тебе не нужно думать, что выражение "Bob's Blog" в конфиге записывается как Bob\'s Blog или Bob's&nbsp;Blog? Да такое есть.

Нет, я не совсем это имел в виду. Логическая организация файла — это когда нужно думать, что нужные тебе данные в конфиге могут выглядеть как variable=value, <variable>value</variable>, variable:value, variable!value или как-то еще.
К твоей задаче (найти нужную переменную) это на самом деле не имеет отношения — просто ненужная добавочная нагрузка.

E>Но вот как быть с поиском по реестру, например?

Не совсем понял, что ты имеешь в виду.

c-smile wrote:

> Достоинства:
> a) human-readable configuration,
> b) произвольная и гибкая структура (мапы/объекты, массивы и остальные
> типы данных JS) — вплоть до функций и классов.
> с) не требуется отдельный механизм парсинга.
> Самому понравилось.

d) Можно устраивать конкурсы obfuscated конфигов.
e) Синтаксис, не поддающийся никакому автоматическому разбору.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Дарней, Вы писали:

Д>Ну это опять же вопрос доступности инструментов. А если стандартизовать единый формат для бинарных конфигов и в каждом дистрибутиве будет удобный редактор/навигатор по нему?

Единый бинарный формат? Да еще удобный. Да еще с продвинутыми инструментами. Да еще чтобы были везде, начиная от Windows и заканчивая Symbian OS или AIX, или NonStop Kernel.

По каждому из пунктов у меня очень большие сомнения.

E>>Т.е. тебе не нужно думать, что выражение "Bob's Blog" в конфиге записывается как Bob\'s Blog или Bob's&nbsp;Blog? Да такое есть.

Д>Нет, я не совсем это имел в виду. Логическая организация файла — это когда нужно думать, что нужные тебе данные в конфиге могут выглядеть как variable=value, <variable>value</variable>, variable:value, variable!value или как-то еще.
Д>К твоей задаче (найти нужную переменную) это на самом деле не имеет отношения — просто ненужная добавочная нагрузка.

А мне кажется, что здесь что-то не так. Если я ищу переменную по имени, то я ищу просто variable. Если я ищу по значению, то ищу просто value.

E>>Но вот как быть с поиском по реестру, например?

Д>Не совсем понял, что ты имеешь в виду.

Ну вот мне вообще интересно, как в реестре сохранять структуры, которые в конфиге легко можно задавать повторяющимися тегами:

{operator
    {id ...}
    ...
    {delivery_receipt
        ...
        {message_state_name {name "DELIVRD"} {state 0x02}}
        {message_state_name {name "REJECTD"} {state 0x08}}
        {message_state_name {name "ACCEPTD"} {state 0x06}}
        ...
    }
}
{operator
    {id ...}
    ...
    {delivery_receipt
        ...
        {message_state_name {name "dlvrd"} {state 0x02}}
        {message_state_name {name "rjctd"} {state 0x08}}
        {message_state_name {name "accptd"} {state 0x06}}
        ...
    }
}

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

Здравствуйте, eao197, Вы писали:

E>Единый бинарный формат? Да еще удобный. Да еще с продвинутыми инструментами. Да еще чтобы были везде, начиная от Windows и заканчивая Symbian OS или AIX, или NonStop Kernel.

E>По каждому из пунктов у меня очень большие сомнения.

Пока таких вариантов и правда не видно. Может быть потому, что в них никто не верит?

E>А мне кажется, что здесь что-то не так. Если я ищу переменную по имени, то я ищу просто variable. Если я ищу по значению, то ищу просто value.

а если это value равно "0", например? получишь в нагрузку целую кучу результатов, из которых надо еще выбрать нужный

E>Ну вот мне вообще интересно, как в реестре сохранять структуры, которые в конфиге легко можно задавать повторяющимися тегами:
E>

E>{operator
E>    {id ...}
E>    ...
E>    {delivery_receipt
E>        ...
E>        {message_state_name {name "DELIVRD"} {state 0x02}}
E>        {message_state_name {name "REJECTD"} {state 0x08}}
E>        {message_state_name {name "ACCEPTD"} {state 0x06}}
E>        ...
E>    }
E>}
E>{operator
E>    {id ...}
E>    ...
E>    {delivery_receipt
E>        ...
E>        {message_state_name {name "dlvrd"} {state 0x02}}
E>        {message_state_name {name "rjctd"} {state 0x08}}
E>        {message_state_name {name "accptd"} {state 0x06}}
E>        ...
E>    }
E>}
E>

E>вот как нужно в реестре сохранить всех операторов и все message_state_name для каждого из операторов. И как затем найти все message_state_name для конкретного оператора?

мы ведь вроде бы говорили про базы данных? а виндовый реестр — и правда неудачная реализация, ИМХО. Взять хотя бы это уродство с регистрацией COMпонентов и множеством зависимостей между ветками, например

Здравствуйте, Cyberax, Вы писали:

>> Достоинства:
>> a) human-readable configuration,
>> b) произвольная и гибкая структура (мапы/объекты, массивы и остальные
>> типы данных JS) — вплоть до функций и классов.
>> с) не требуется отдельный механизм парсинга.
>> Самому понравилось.

C>d) Можно устраивать конкурсы obfuscated конфигов.
C>e) Синтаксис, не поддающийся никакому автоматическому разбору.

Вот ты прикалываешься, а если разработка идет на скриптовых языках, то конфигурирование приложения на самом скриптовом языке может быть вполне нормальным явлением. Например:
http://www.rubygarden.org/index.cgi/Libraries/copland-to-needle.rdoc
http://onestepback.org/index.cgi/Tech/Ruby/DependencyInjectionInRuby.rdoc

Там идея в том, что благодоря реализации Dependency Injection можно конфигурировать приложение не конфигурационным файлом, а непосредственно скриптом:

def create_application
    container = DI::Container.new
    container.register(:logfilename) { "logfile.log" }
    container.register(:db_user) { "jim" }
    container.register(:db_password) { "secret" }
    container.register(:dbi_string) { "DBI:Pg:example_data" }

    container.register(:app) { |c|
        app = WebApp.new(c.quotes, c.authenticator, c.database)
        app.logger = c.logger
        app.set_error_handler c.error_handler
        app
    }

    container.register(:quotes) { |c|
        StockQuotes.new(c.error_handler, c.logger)
    }

    container.register(:authenticator) { |c|
        Authenticator.new(c.database, c.logger, c.error_handler)
    }

    container.register(:database) { |c|
        DBI.connect(c.dbi_string, c.db_user, c.db_password)
    }

    container.register(:logger) { |c| Logger.new(c.logfilename) }
    container.register(:error_handler) { |c|
        errh = ErrorHandler.new
        errh.logger = c.logger
        errh
    }
end

Собственно, если попробовать развить идею дальше, то можно вполне представить себе C++ приложение, которое собирается Ruby (Python, Tcl/Tk) скриптом в единое целое.

Здравствуйте, Дарней, Вы писали:

E>>По каждому из пунктов у меня очень большие сомнения.

Д>Пока таких вариантов и правда не видно. Может быть потому, что в них никто не верит?

А неверит потому, что одна половина сомневается в возможности создания таких инструментов, а вторая половина сомневается в необходимости подобных инструментов

E>>А мне кажется, что здесь что-то не так. Если я ищу переменную по имени, то я ищу просто variable. Если я ищу по значению, то ищу просто value.

Д>а если это value равно "0", например? получишь в нагрузку целую кучу результатов, из которых надо еще выбрать нужный

Элементарно
grep -r "0" *.cfg | grep "reconnect-timeout"

Д>мы ведь вроде бы говорили про базы данных? а виндовый реестр — и правда неудачная реализация, ИМХО. Взять хотя бы это уродство с регистрацией COMпонентов и множеством зависимостей между ветками, например

Ну мы тут не только про базы данных говорили
Но, с другой стороны, это программисту легко sql-ный select слабать, чтобы по нескольким таблицам выборку сделать. А вот имеет ли смысл требовать того же от администратора?

Здравствуйте, Дарней, Вы писали:

Д>Ну это опять же вопрос доступности инструментов. А если стандартизовать единый формат для бинарных конфигов и в каждом дистрибутиве будет удобный редактор/навигатор по нему?

Интересно, а какой плюс дает "бинарность" конфига? Что мешает тебе стандартизовать формат текстового конфига и гонять запросы по нему?

Ну, пусть это будет XML. Запросы — XPath, редактирование в GUI делается на основе схемы.

Зачем бинарность-то нужна?

Здравствуйте, WFrag, Вы писали:

WF>Интересно, а какой плюс дает "бинарность" конфига? Что мешает тебе стандартизовать формат текстового конфига и гонять запросы по нему?

WF>Ну, пусть это будет XML. Запросы — XPath, редактирование в GUI делается на основе схемы.

WF>Зачем бинарность-то нужна?

А зачем тебе текстовость нужна, если ты все равно будешь использовать специальный инструмент для его редактирования и навигации по нему? У твоего компьютера слишком много свободных ресурсов? (только не бейте меня ногами за это вульгарное слово — производительность )
Я не знаю как остальные, но лично меня напрягает, когда моя система скрипит под тяжестью какой-нибудь программулины с моднейшими XML-ными хранилищами данных.
Оперативки мало, говорите? Нет, вы серьезно уверены, что гиг оперативки — это мало?

Здравствуйте, eao197, Вы писали:

E>grep -r "0" *.cfg | grep "reconnect-timeout"

то есть ты уже знаешь, какой на самом деле параметр тебе нужен

ну а все таки? Как бы ты извлек список расширений, которые подключены к серверу MySQL?

E>Ну мы тут не только про базы данных говорили
E>Но, с другой стороны, это программисту легко sql-ный select слабать, чтобы по нескольким таблицам выборку сделать. А вот имеет ли смысл требовать того же от администратора?

Только не говори, что регулярные выражения проще, чем SQL.

Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, eao197, Вы писали:

E>>grep -r "0" *.cfg | grep "reconnect-timeout"

Д>то есть ты уже знаешь, какой на самом деле параметр тебе нужен

Ну да. Более того, в своих конфигах я даже знаю, как этот параметр будет записан, поэтому могу и без конвейера grep-ов обойтись.

Д>ну а все таки? Как бы ты извлек список расширений, которые подключены к серверу MySQL?

Никогда не работал с MySQL, ничего не могу сказать по этому поводу.

E>>Ну мы тут не только про базы данных говорили
E>>Но, с другой стороны, это программисту легко sql-ный select слабать, чтобы по нескольким таблицам выборку сделать. А вот имеет ли смысл требовать того же от администратора?

Д>Только не говори, что регулярные выражения проще, чем SQL.

Не проще, однозначно. Хотя и SQL с его join-ами подводные камни имеет. Ну и кроме того, regex мощнее, чем LIKE в SQL.
Но grep уж точно на таком огромном количестве платформ есть, что и не сосчитаешь с ходу.

Здравствуйте, Дарней, Вы писали:

Д>(только не бейте меня ногами за это вульгарное слово — производительность )

И какой же выигрыш в производительности приложения планируется получить, даже если уменьшить время чтения конфига в 100 раз?

Д>Я не знаю как остальные, но лично меня напрягает, когда моя система скрипит под тяжестью какой-нибудь программулины с моднейшими XML-ными хранилищами данных.

Пожалуйста, не надо путать конфигурацию приложения и данные, обрабатываемые приложением. Это разные вещи, хотя граница иногда и размыта.

Здравствуйте, Дарней, Вы писали:

Д>А зачем тебе текстовость нужна, если ты все равно будешь использовать специальный инструмент для его редактирования и навигации по нему?

Уже сто раз объясняли. diff, grep, find, patch, awk, vim, и.т.д. Мне так никто и не объяснил, зачем от них отказываться. Пусть даже и при наличии "специальных инструментов".

Например, ты сделаешь для своих конфигов аналог трехточечного diff-а (который используется в CVS)? Или аналог cvs blame (не знаю, правда, зачем ).

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

Д>У твоего компьютера слишком много свободных ресурсов? (только не бейте меня ногами за это вульгарное слово — производительность )

Основные ресурсы, как правило, идут отнюдь не на разбор конфига.

Д>Я не знаю как остальные, но лично меня напрягает, когда моя система скрипит под тяжестью какой-нибудь программулины с моднейшими XML-ными хранилищами данных.

Тю. Так то данные.

Здравствуйте, А почему вы спрашиваете, Вы писали:

ПК>>Вопрос такой: как ты относишься к выбору между XML, INI-подобными файлами и custom formats?

АПВ>К XML'ю для конфигов я отношусь скептически, все-таки XML весьма условно human readable и практически не human writable — уж больно многословен. Что касается INI-style vs. все остальное, то тут у меня явных предпочтений нет. Главное, чтобы "костюмчик сидел" — чтобы язык конфига был адекватен задаче. В простых случаях INI будет достачно, в случаях посложней, должен окупиться собственный формат.

Собственно, вот и ответ любителям использовать XML по любому чиху. Надо уметь правильно расставлять приоритеты между удобством пользования и удобством разработки.

eao197,

E>Ну вот мне вообще интересно, как в реестре сохранять структуры, которые в конфиге легко можно задавать повторяющимися тегами:
E>

E>{operator
E>    {id ...}
E>    ...
E>}
E>

Немного не в тему, такой вопрос: а чем был обусловлен выбор фигурной скобки вместо круглой?

Здравствуйте, Lazy Cjow Rhrr, Вы писали:

E>>Ну вот мне вообще интересно, как в реестре сохранять структуры, которые в конфиге легко можно задавать повторяющимися тегами:
E>>

E>>{operator
E>>    {id ...}
E>>    ...
E>>}
E>>

LCR>Немного не в тему, такой вопрос: а чем был обусловлен выбор фигурной скобки вместо круглой?

На меня в свое время произвел впечатление язык Curl. Настолько, что я сделал для себя библиотеку, которую использую для хранения конфигов в синтаксисе Curl-а.
Но здесь эту тему уже обсуждали: Формат конфигов

Автор: VladD2
Дата: 19.06.05

-- многим кажется, что XML -- это единственный подходящий для конфигов формат Я так не думаю

Здравствуйте, eao197, Вы писали:

E>Собственно, если попробовать развить идею дальше, то можно вполне представить себе C++ приложение, которое собирается Ruby (Python, Tcl/Tk) скриптом в единое целое.

В принципе идея "клеевых" языков в общем и целом не нова, согласен.
Java та же если не выпендриваться в стиле "все на java" вельми как хороша для этого.

В моем конкретном случае (например BlockNote) получается целый класс функций
которые просятся в скрипт. Например формирование TOC по набору H1-H6 тэгов в документе.
Еще одна пользительная фенечка — code coloriser встроенный в редактор для разных типов
исходников и пр. Собственно модули разбора синтаксиса разных языков и есть
части config'a. Пользователи часто просят всякие мелочи, но ломает же ведь каждый раз суровым програмизмом заниматься.