eao197,

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

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

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

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

Интересно. Только вот ещё странно: произвёл впечатление Curl, а пишешь на Сипласплас

ххх: лично меня XML раздражает избыточностью. Поэтому ну его в баню

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

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

LCR>Интересно. Только вот ещё странно: произвёл впечатление Curl, а пишешь на Сипласплас

Да ничего странного
Во-первых, Curl задумывался как новый язык для Web-разработки. Ну и для GUI он мог бы подойти. А я сейчас больше по серверным приложениям из области телекоммуникаций специализируюсь.
Во-вторых, Curl не оправдал возлагавшихся на него надежд. Несколько лет назад я слышал, что Curl Corporation был скуплен на корню японцами, которые успешно его применяют для создания внутрикорпоративных Intranet систем. Такой узкоспециализированный нишевой продукт получился.

eao197,

E>... Curl ... узкоспециализированный нишевой продукт получился.

Ясненько. Спасибо за информацию.

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

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

а скорость чтения рабочих данных приложения?

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

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

две стороны одной медали Вса аргументы, которые можно высказать про один из них, так же можно перенести и на другой.

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

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

вот-вот. Нужно иметь информацию не только о нужных тебе параметрах, но и о том, как они представлены в данном конфиге (уточню — каждом данном конфиге).

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

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

E>Не проще, однозначно. Хотя и SQL с его join-ами подводные камни имеет. Ну и кроме того, regex мощнее, чем LIKE в SQL.

Просто потому, что у регэксов нет никаких возможностей строить более сложные запросы, чем плоский поиск по файлу (есть еще конечно look ahead/look behind, но пользы от них не так уж много. А уж в применении они точно куда сложнее, чем join)

E>Но grep уж точно на таком огромном количестве платформ есть, что и не сосчитаешь с ходу.

SQL тоже

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

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

Ради более продвинутых инструментов, например.

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

Если ты лично уже натренировался так, что у тебя это на уровне подсознания происходит — это не значит, что проблемы нет вообще. Меня например это напрягает.

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

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

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

Д>Ради более продвинутых инструментов, например.

"Продвинутые" в каком плане? Более универсальные, более мощные или какие-то еще?

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

Д>Если ты лично уже натренировался так, что у тебя это на уровне подсознания происходит — это не значит, что проблемы нет вообще. Меня например это напрягает.

Что на уровне подсознания? Чтение документации перед тем, как что-то пытаться поправить? Согласен, принцип "поставим галочку, а потом посмотрим, что произойдет" в случае ручного редактирования текстовых конфигов мало применим (однако никто не мешает пользоваться "высокоуровневыми" средствами, если они есть, конечно, но это уже другой вопрос ).

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

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

Это зависит от типа данных. Базу данных платежных транзакций или сообщения RSDN@Home я вряд ли смогу восстановить вручную. Другие задачи, другие требования

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

WF>"Продвинутые" в каком плане? Более универсальные, более мощные или какие-то еще?

и то, и другое, я думаю

WF>Что на уровне подсознания? Чтение документации перед тем, как что-то пытаться поправить? Согласен, принцип "поставим галочку, а потом посмотрим, что произойдет" в случае ручного редактирования текстовых конфигов мало применим (однако никто не мешает пользоваться "высокоуровневыми" средствами, если они есть, конечно, но это уже другой вопрос ).

Чтение документации, чтобы посмотреть, какие разделители надо ставить в списке значений, например.

WF>Это зависит от типа данных. Базу данных платежных транзакций или сообщения RSDN@Home я вряд ли смогу восстановить вручную. Другие задачи, другие требования

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

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

Д>и то, и другое, я думаю

Такого не бывает

Например, я часто в комментариях оставляю куски конфига. Или пояснения. Очень полезная возможность. И основана она именно на том, что в plain-text конфиги (как правило) можно вставлять любой текст (в комментарии), без учета специфики конфига. А потом изменением пары символов включать или выключать ту или иную часть.

Д>Чтение документации, чтобы посмотреть, какие разделители надо ставить в списке значений, например.

Ой, да не смеши. Это пять-десять минут максимум. Полное осознание конфига того же Апача — час как минимум.

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

Ну я же сказал — данные как правило гораздо сложнее вручную восстановить. Только бэкап (хотя, для конфигов та же ерунда на самом деле)

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

WF>Такого не бывает

я надеюсь, что все-таки бывает

WF>Например, я часто в комментариях оставляю куски конфига. Или пояснения. Очень полезная возможность. И основана она именно на том, что в plain-text конфиги (как правило) можно вставлять любой текст (в комментарии), без учета специфики конфига. А потом изменением пары символов включать или выключать ту или иную часть.

ну.. для базы данных это чуть сложнее, но никаких принципиальных проблем тут нет.

WF>Ой, да не смеши. Это пять-десять минут максимум. Полное осознание конфига того же Апача — час как минимум.

когда думаешь только о решении своей задачи, даже 5 минут — это неприятно. Здесь 5 минут, там 5 минут — потом уже и забудешь, чего сначала хотел

WF>Ну я же сказал — данные как правило гораздо сложнее вручную восстановить. Только бэкап (хотя, для конфигов та же ерунда на самом деле)

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

Здравствуйте, Дарней, Вы писали:
WF>>А что считать "приложением"? Как отделить одно приложение от другого?
Д>например — процесс, запущенный из заданного бинарного файла
Идея, конечно, замечательная. Вот только проблема не имеет никакого отношения ни к ФС, ни к реестру. Проблема — в самой системе безопасности. Когда проектировалась NT, никто не предполагал нужды в CAS. Времена изменились; теперь все не так, как раньше. Модель безопасности в управляемой среде значительно сложнее, и она как раз включает раздачу привилегий не только пользователям, но и коду. Причем от самих ресурсов в общем-то ничего умного и не надо. Все проверяет рантайм.

З.Ы. Кое-где в нативной винде тем не менее применяются проверки запускающего приложения. Например, некоторые функции WinLogon можно запускать только из логон-сервиса. Можно написать свою GINA DLL, которая получит доступ к этим функциям, благодаря тому, что ее загрузят в адресное пространство соответствующего процесса. Но написать свое приложение, которое будет обращаться к этим функциям мимо стандартного сервиса, не выйдет.

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

S>Вот только проблема не имеет никакого отношения ни к ФС, ни к реестру. Проблема — в самой системе безопасности.

согласен

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

S>З.Ы. Кое-где в нативной винде тем не менее применяются проверки запускающего приложения.

Нигде и никогда. Это вообще возможно только в управляемом коде.

S> Например, некоторые функции WinLogon можно запускать только из логон-сервиса.

Нет. Есть понятие привелегий. С каждым процессом или потоком ассоциируется токен защиты. Некоторые учетные записи имеют больше привелегий. Некоторые меньше. Некоторые привелегии по умолчанию выключены. Некоторые нет. От этого изависит что и где можно вызывать. У учетной записи System есть некоторые привелегии недоступные другим. По этому некоторые вызовы можно сделать только из под нее. Ну, а с нулевого кольца защиты вообще нет ничего недостижимого. Тот же СофтАйс внаглую тормозит любое виндовое приложение и лезет в память. Я как-то Квэйк3 тормозил во время игры.

S> Можно написать свою GINA DLL, которая получит доступ к этим функциям, благодаря тому, что ее загрузят в адресное пространство соответствующего процесса. Но написать свое приложение, которое будет обращаться к этим функциям мимо стандартного сервиса, не выйдет.

Были бы функции доступны. А при желании вызвать можно хоть черта лысого.

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

VD>Нигде и никогда. Это вообще возможно только в управляемом коде.
Да, виноват. Похоже, я что-то неправильно понял, когда занимался этим в последний раз. Сейчас перечитал — достаточно иметь привилегию SeTcbPrivilege.

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

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

Д>вот-вот. Нужно иметь информацию не только о нужных тебе параметрах, но и о том, как они представлены в данном конфиге (уточню — каждом данном конфиге).

Свежий пример: потребовалось мне сегодня просмотреть, какие IP адреса разные компоненты используют. У каждого компонента собственная структура конфига. Общее только то, что IP адрес записывается в теге {ip}. Для получения списка всех IP я просто зашел в каталог с конфигами, выполнил поиск:

grep -r -E "\{ip[[:space:]]" .

и получил все, что мне нужно. Совершенно не заботясь о том, для каких тегов {ip} является дочерним в каждом из конфигов. Более того, даже если бы я не знал, в каких именно тегах записываются IP-шники, я мог запустить grep с другим regexp-ом:

grep -r -E "(([[:digit:]]{1,3}\.){3}[[:digit:]]{1,3}):[[:digit:]]+" .

А вот если бы конфигурация хранилась в SQL БД и каждый компонент хранил бы настройки в своей таблице, как бы мне тогда пришлось получать список IP-шников (даже если в каждой таблице IP хранится в столбце с именем "IP")?

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

E>Свежий пример: потребовалось мне сегодня просмотреть, какие IP адреса разные компоненты используют. У каждого компонента собственная структура конфига. Общее только то, что IP адрес записывается в теге {ip}. Для получения списка всех IP я просто зашел в каталог с конфигами, выполнил поиск:
E>

E>grep -r -E "\{ip[[:space:]]" .
E>

E>и получил все, что мне нужно. Совершенно не заботясь о том, для каких тегов {ip} является дочерним в каждом из конфигов. Более того, даже если бы я не знал, в каких именно тегах записываются IP-шники, я мог запустить grep с другим regexp-ом:
E>

E>grep -r -E "(([[:digit:]]{1,3}\.){3}[[:digit:]]{1,3}):[[:digit:]]+" .
E>

E>А вот если бы конфигурация хранилась в SQL БД и каждый компонент хранил бы настройки в своей таблице, как бы мне тогда пришлось получать список IP-шников (даже если в каждой таблице IP хранится в столбце с именем "IP")?

А вот если бы в одном конфиге тэг назывался host_address, а не ip? А сам адрес записывался бы в шестнадцатеричной форме? Как бы тебе тогда пришлось его получать?

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

E>>А вот если бы конфигурация хранилась в SQL БД и каждый компонент хранил бы настройки в своей таблице, как бы мне тогда пришлось получать список IP-шников (даже если в каждой таблице IP хранится в столбце с именем "IP")?

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

Хранить IPv4 сразу в шестнадцатиричном виде? Это оригинально
А такое вообще бывает?

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

E>Хранить IPv4 сразу в шестнадцатиричном виде? Это оригинально
E>А такое вообще бывает?

Ну если очень хочется, то можно.

C:\>ping 2130706433

Обмен пакетами с 127.0.0.1 по 32 байт:

Ответ от 127.0.0.1: число байт=32 время<10мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<10мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<10мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<10мс TTL=128

Статистика Ping для 127.0.0.1:
    Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),
Приблизительное время передачи и приема:
    наименьшее = 0мс, наибольшее =  0мс, среднее =  0мс

C:\>ping 0x7F000001

Обмен пакетами с 127.0.0.1 по 32 байт:

Ответ от 127.0.0.1: число байт=32 время<10мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<10мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<10мс TTL=128
Ответ от 127.0.0.1: число байт=32 время<10мс TTL=128

Статистика Ping для 127.0.0.1:
    Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),
Приблизительное время передачи и приема:
    наименьшее = 0мс, наибольшее =  0мс, среднее =  0мс

Но рассчитывать на такую запись в конфигах я бы не стал. Если администратор такое сделал, то ССЗБ. Но вот если речь о данных получаемых от пользователя, то на такое надо проверять обязательно.

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

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

E>>>А вот если бы конфигурация хранилась в SQL БД и каждый компонент хранил бы настройки в своей таблице, как бы мне тогда пришлось получать список IP-шников (даже если в каждой таблице IP хранится в столбце с именем "IP")?

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

E>Хранить IPv4 сразу в шестнадцатиричном виде? Это оригинально
E>А такое вообще бывает?
Суть вопроса была не в этом

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

E>>>>А вот если бы конфигурация хранилась в SQL БД и каждый компонент хранил бы настройки в своей таблице, как бы мне тогда пришлось получать список IP-шников (даже если в каждой таблице IP хранится в столбце с именем "IP")?

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

E>>Хранить IPv4 сразу в шестнадцатиричном виде? Это оригинально
E>>А такое вообще бывает?
I>Суть вопроса была не в этом

А в чем?
Если какой-то IP задан в шестнадцатиричном виде, то:

grep -r -E "((([[[:digit:]]{1,3}\.){3}[[[:digit:]]{1,3}|[[[:xdigit:]]{8})){0,1}:[[[:digit:]]+" .

А я так и не понял, как аналогичный поиск сделать в SQL БД. Чтобы сразу по всем таблицам с конфигурациями.