Что придёт на смену xorg.conf?

Я не возьмусь утверждать. Но моя мысль в том, что в самом XPath нигде в явном виде завязка на DOM не завязана. Не говоря уж про хранение DOM в ОЗУ - например, кто запрещает перемолотить DOM во внутреннее представление (на диске!), оптимизированное для конкретной схемы и конкретного паттерна XPath запросов? Конечно, никто такой фигней не занимается...

>Но моя мысль в том, что в самом XPath нигде в явном виде завязка на DOM не завязана.

На уровне API в нашем хересе и ихнем m$xml. Кроме того, исторически это подъязык в другой DOM-технологии под названием xsl.

Ок, да, про дом я погорячился немного. А завязка на ОЗУ где?

>Ок, да, про дом я погорячился немного. А завязка на ОЗУ где?

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

> Еще раз - что ты предлагаешь?

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

> например, кто запрещает перемолотить DOM во внутреннее представление (на диске!), оптимизированное для конкретной схемы и конкретного паттерна XPath запросов? Конечно, никто такой фигней не занимается...

Такой фигней -- никто. А вот внутренним представлением на диске -- сколько угодно занимаются. И это опять же возвращает нас к предмету дискуссии.

>> Еще раз - что ты предлагаешь?

>Я предлагаю ускоренно переболеть болезнью сооружения универсальных форматов.

Еще раз - что ты предлагаешь для промышленного применения кроме Oracle/DB2/M$SQL/... или их опенсорцных аналогов? Предлагай, поржем.

>> Я предлагаю ускоренно переболеть болезнью сооружения универсальных форматов.

> Еще раз - что ты предлагаешь для промышленного применения кроме Oracle/DB2/M$SQL/... или их опенсорцных аналогов? Предлагай, поржем.

Что-то я за твоей логикой уследить не смог: когда произошёл перескок с gconf на RDBMS?

>>> Я предлагаю ускоренно переболеть болезнью сооружения универсальных форматов.

>> Еще раз - что ты предлагаешь для промышленного применения кроме Oracle/DB2/M$SQL/... или их опенсорцных аналогов? Предлагай, поржем.

>Что-то я за твоей логикой уследить не смог: когда произошёл перескок с gconf на RDBMS?

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

>>> Еще раз - что ты предлагаешь для промышленного применения кроме Oracle/DB2/M$SQL/... или их опенсорцных аналогов? Предлагай, поржем.

>> Что-то я за твоей логикой уследить не смог: когда произошёл перескок с gconf на RDBMS?

> Когда речь зашла об неиллюзорной убогости SQL и сравнении написания произвольной модели данных на SQL с написанием произвольной программы на брейнфаке.

И из этого ты вывел мою ненависть к rdbms? Не вижу правомерности такого перехода.

Раз уж ты задал такой вопрос, то я считаю что rdbms+sql хороши в подавляющем большинстве случаев их промышленного применения. Примеры мест, где обрабатываются огромные объёмя данных, но sql не применяется и даже времен, я думаю, ты способен привести и сам.

объёмя -> объёмы, времен -> вреден

> когда произошёл перескок с gconf на RDBMS?

А кто мешает подложить под интерфейс нормальную СУБД? Кто-то может извращаться и хранить настройки в гигантском и неэффективном ХМЛ-файле, а у остальных будет свобода подпихнуть шуструю базку под это дело.

>> Ты парадоксальную для себя ситуацию с Oracle и BerkleyDB уже разрулил?:) > BerkleyDB - это типа B* дерева с парами key=value?

А он сам не понимает про что спрашивает.

> Способ доступа один - чтение блока с HDD и отсекание от него всего ненужного. Для того чтобы определить местоположение этого блока, и оффсет + длину искомых данных нужен езыг.

А для эффективного поиска нужны ещё индексы, которых нет в ХМЛ. А для работы в многозадачной системе нужны ещё и транзакции. А для того, что бы байты друг другу не противоречили нужны ещё ограничения целостности, впрочем последнее в ХМЛ присутствует.

>> когда произошёл перескок с gconf на RDBMS?

> А кто мешает подложить под интерфейс нормальную СУБД? Кто-то может извращаться и хранить настройки в гигантском и неэффективном ХМЛ-файле, а у остальных будет свобода подпихнуть шуструю базку под это дело.

Мешает только одно -- попытка впихнуть всё множество возможных способов сохранить конфиг в формат /path/to/key=value.

> впихнуть всё множество возможных способов сохранить конфиг

Читал - много думал. ХМЛ - это один из способов сохранить конфиг, база данных - другой способ сохранить конфиг. Какое втискивание?

>> впихнуть всё множество возможных способов сохранить конфиг

> Читал - много думал. ХМЛ - это один из способов сохранить конфиг, база данных - другой способ сохранить конфиг. Какое втискивание?

Втискиваться оно в базу или в xml будет с помощью Универсального Апи, за которое так ратуют некоторые. И они же считают, что /path/to/key=value будет достаточно всем и каждому.

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

>Мешает только одно -- попытка впихнуть всё множество возможных способов сохранить конфиг в формат /path/to/key=value.

кто-нибудь, спросите это чудо, чем ему это мешает.

А то он меня заигнорил, потому что ему нечего ответить =)

Так пускай втискивается где-нибудь там, под уровнем SQL. Главное что бы не видеть этого ужоса и иметь возможность заменить такое безобразие на нормальную БД.

> кто-нибудь, спросите это чудо, чем ему это мешает.

А ты сам не понимаешь, что не нужно притравливать софт на какой-то специфический АПИ в то время как можно использовать обычный JDBC/ODBC датасурс, нормально абстрагирующий приложения от особенностей реализации хранилища в той или иной конфигурации?

> Так пускай втискивается где-нибудь там, под уровнем SQL. Главное что бы не видеть этого ужоса и иметь возможность заменить такое безобразие на нормальную БД.

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

Ибо не все данные можно тривиально захоронить в дерево. И не все конфиги в частности.

Если не нравится избитый пример про sendmail.cf, могу предоставить другой: конфиг банкомата или платёжного терминала, представленной как машина состояний. Его в дерево не сохранишь из-за наличия циклов.

>А ты сам не понимаешь, что не нужно притравливать софт на какой-то специфический АПИ в то время как можно использовать обычный JDBC/ODBC датасурс

я там выше писал про вебдизигнера, у которого sql генерилось на стороне клиента. Предлагаю подумать о подводных камнях такого подхода.

Не вижу препятствий, если честно.

попытка Strogg-ов, вломиться сюда и доказать умопомрачительную полезность, столь любимых ими "централлизованный", "унификация", "эффективное" - ПРОВАЛИЛАСЬ! в мире UX - этого всего нет, не потому что оно плохо или хорошо, оно просто ТАМ - Ненужно! прекраная была аналогия с булатными ножиками, которыми можно тнаковые стволы рубить и арматуру и "шипотребом из под пресса", которым не всегда - можно "эффективно" (tm) отрезать кусок хлеба.

> я там выше писал про вебдизигнера, у которого sql генерилось на стороне клиента. Предлагаю подумать о подводных камнях такого подхода.

А смысл?

>А смысл?

Смысл?

>> конфиг банкомата или платёжного терминала, представленной как машина состояний. Его в дерево не сохранишь из-за наличия циклов.

> Не вижу препятствий, если честно.

Ну а ты попробуй предоставить свой вариант. И я спрошу как минимум один вопрос.

# echo $question | md5sum
8294d85cf000d21b9e7fe626624f99b7 -

> Ну а ты попробуй предоставить свой вариант.

Свой вариант чего?

> И я спрошу как минимум один вопрос

Наивно надеешься, что я сломаю моск?

>попытка Strogg-ов, вломиться сюда

Это подражание оберфюреру Яроврату чтоли? Тот прихвостней ЕРЖ тоже классифицировал по типам зергов/строггов/орков.

>> Ну а ты попробуй предоставить свой вариант.

> Свой вариант чего?

Сохранения конфига нашеё сферической машины состояний в дерево.

>> И я спрошу как минимум один вопрос

> Наивно надеешься, что я сломаю моск?

Нет, просто чтоб ты убедился, что вопрос я знаю заранее. Хотя можешь получить вопрос перебором, там всего три слова. Кодировка utf8 :)

Вы доставляете. Это я из сиетла вам говорю йо.

Фрагментация это то орудие которым вас просто превратят в булькающую дерьмом массу, да.

> Сохранения конфига нашеё сферической машины состояний в дерево.

Да запросто. Выделяешь ноду, в которой дочерними состояниями описываешь все состояния машины: ... <machine id="0"> <states> <state id="0"> <register name="accumulator" value="0x20" />... </state> <state id="1"> ... etc ...

и такую же хрень для переходов: <program id="0"> <switches> <switch id="0" type="conditional" condition="blabla" stateIfTrue="0" stateIfFalse="14"> и т.д.

Реляционные данные на иерархическую модель отображаются без проблем и обратно тоже. Только в случае с XML оверхед получается жуткий и поиск данных производится крайне неэффективно. Но это не повод отказывать некоторым нашим товарищам в возможности сохранять данные и в XML тоже - лучше дать им такую возможность, вони будет меньше.

Теперь задавай свой вопрос :-)

> Реляционные данные на иерархическую модель отображаются без проблем и обратно тоже. Только в случае с XML оверхед получается жуткий и поиск данных производится крайне неэффективно. Но это не повод отказывать некоторым нашим товарищам в возможности сохранять данные и в XML тоже - лучше дать им такую возможность, вони будет меньше.

Ещё покажи, как именно всё это сохранять через Универсальный Древесный Апи /path/to/key=value. Ну или пусть любители УДА покажут.

> Теперь задавай свой вопрос :-)

$ echo 'Как проводить валидацию?' | md5sum
8294d85cf000d21b9e7fe626624f99b7 -

Т.е. как проверить, что stateIf{True,False} указывает на существующий state.

> Главное что бы не видеть этого ужоса и иметь возможность заменить такое безобразие на нормальную БД.

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

Нет, уже если выбирать между конфигом на tcl/python/s-exp/etc и "нормальной бд", то хер с ней, с унификацией, это хотя бы всегда можно поправить в текстовом редакторе. Да и зумель, хоть и не очень удобно, но вполне возможно.

> Ещё покажи, как именно всё это сохранять через Универсальный Древесный Апи /path/to/key=value. Ну или пусть любители УДА покажут.

Прогу я тебе по памяти не напишу, года четыре уже как с ХМЛ не работаю. Но ничего сложного в том нет: загружаешь XML-ку в объект DOM, у ДОМа просишь ноду, соответствующую твоему /path/to, ищешь в её чилдах вхождение интересующего тебя key - если есть вправляешь ему value, если нету - создаёшь нужный. Когда перестаёшь работать с DOM - сериализуешь его обратно в хранилище в XML.

> как проверить, что stateIf{True,False} указывает на существующий state.

Не знаю. Возможно в XML Schema появились какие-нибудь средства. Однако, если бы я делал, я бы просто определил для нод аттрибуты onInsertChild, onDeleteChild, onUpdate, onUpdateChild в которых задавал бы соответствующие фукции/выражения валидации, текст которых лежал бы в тех же ХМЛ, язык для функций - JavaScript как наиболее универсальный.

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

Вообще-то речь не о конфигурации загрузчика|йадра идёт. А с точки зрения танцев с бубном - со структурированной информацией всё работать проще, чем с огромным блобом фацловой системы, набитым всякими мелкими файликами, по которым конфигурация размазана в самых разных безобразных формах представления.

>> Ещё покажи, как именно всё это сохранять через Универсальный Древесный Апи /path/to/key=value. Ну или пусть любители УДА покажут.

> Прогу я тебе по памяти не напишу, года четыре уже как с ХМЛ не работаю. Но ничего сложного в том нет: загружаешь XML-ку в объект DOM, у ДОМа просишь ноду, соответствующую твоему /path/to...

Не так. Вот есть у меня УДА, предоставляющий функции saveConfig(path, key, value) и loadConfig(path,key). И как мне этим достать конфиг моего банкомата?

>> как проверить, что stateIf{True,False} указывает на существующий state.

> Не знаю. Возможно в XML Schema появились какие-нибудь средства.

Ясно, отсутствие валидации защитано.

> Однако, если бы я делал, я бы просто определил для нод аттрибуты onInsertChild, onDeleteChild, onUpdate, onUpdateChild в которых задавал бы соответствующие фукции/выражения валидации, текст которых лежал бы в тех же ХМЛ, язык для функций - JavaScript как наиболее универсальный.

То есть ты изобрёл xul. Брависсимо! :)

> А с точки зрения танцев с бубном - со структурированной информацией всё работать проще, чем с огромным блобом фацловой системы, набитым всякими мелкими файликами, по которым конфигурация размазана в самых разных безобразных формах представления.

А вот это ещё бабушка надвое сказала. Каждый файл структурирован согласно решаемой задаче. А в базе будет лежать универсальноё чёрти что, например, упорядоченный набор лексем.

> Не так. Вот есть у меня УДА, предоставляющий функции saveConfig(path, key, value) и loadConfig(path,key). И как мне этим достать конфиг моего банкомата?

Так и доставать. В чём проблема? Конечно из БД это всё досталось бы в один селект.

> Ясно, отсутствие валидации защитано.

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

> То есть ты изобрёл xul. Брависсимо! :)

У нас так всегда получается, когда начинаем изобретать велосипеды, забивать гвозди микроскопом и пытаться использовать что-то отличное от СУБД для управления данными..

Если выставить на печать этот топик, то получится 474 страницы.

Толсто.

> А вот это ещё бабушка надвое сказала. Каждый файл структурирован согласно решаемой задаче. А в базе будет лежать универсальноё чёрти что, например, упорядоченный набор лексем.

Не надо бояться базы данных. Если тебе нужно что-то, что на базу не ложится (а я такого примера так за весь тред и не встретил) - тебе никто не мешает воспользоваться просто блобом для хранения твоего уникального значения, или картинки из банкомата.

А что до решаемой задачи - то лично для меня наипервейшей задачей видится избавиться от файликов *.dpkg после каждого дистапгрейда. В 99% случаев в конфигурацию можно было бы просто добавить новые ключи со значениями и не заморачиваться. Только вот программам самим неудобно анализировать собственные конфиги в форме текстовых файликов, вот и приходится каждый раз в ручную всё восстанавливать. Надеюсь это исчезнет с переходом на хранение конфигов в БД. А не исчезнет, то с этим всё равно будет проще бороться в несколько заклинаний на SQL.

> Так и доставать. В чём проблема? Конечно из БД это всё досталось бы в один селект.

Доставать проблемы нет. Проблема в том, как будут внутренние данные отображаться на базу/зюмель и обратно.

>> Ясно, отсутствие валидации защитано.

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

А без валидации неинтересно.

>> То есть ты изобрёл xul. Брависсимо! :)

> У нас так всегда получается, когда начинаем изобретать велосипеды, забивать гвозди микроскопом и пытаться использовать что-то отличное от СУБД для управления данными.

Отлично, покажи мне таблицу базы, в которую можно занести конфиг любого типа.

>>> как проверить, что stateIf{True,False} указывает на существующий state.

>> Не знаю. Возможно в XML Schema появились какие-нибудь средства.

>Ясно, отсутствие валидации защитано.

Семантику можно с помощью xsl проверить - чисто декларативный Тюринг-полный язык кстати. Синтаксис - xsd, семантика - xsl. Вполне нормальное разделение.

>> Ясно, отсутствие валидации защитано.

> Семантику можно с помощью xsl проверить - чисто декларативный Тюринг-полный язык кстати. Синтаксис - xsd, семантика - xsl. Вполне нормальное разделение.

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

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

В настоящий момент стало быть все дотошно проверяют конфиги? Лично мне бы xsd вполне хватило для того чтобы избежать синтаксических ошибок типа пропущенной буквы в написании ключа или заведомо неправильных значений параметров. Куча имеющегося кода такой параметр просто пропустят и возьмут дефолтное значение, что может привести к иллюзии правильной работы с последующим неожиданным 3.1416децом впоследствии.

BTW Ясли бы я принял решение применять xsl я бы не только проверял xml файл но и эффективно экстрактил из него данные. Т.е без быдлокода на Яве/Плюсах, итеративно блуждающего по DOM-узлам.

> BTW Ясли бы я принял решение применять xsl я бы не только проверял xml файл но и эффективно экстрактил из него данные.

Экстрактил бы куда? В еще какой-то формат, обрабатываемый другим быдлокодом?

>> BTW Ясли бы я принял решение применять xsl я бы не только проверял xml файл но и эффективно экстрактил из него данные.

>Экстрактил бы куда? В еще какой-то формат, обрабатываемый другим быдлокодом?

В DOM-узел с результатом, не требующим обработки.

> BTW Ясли бы я принял решение применять xsl я бы не только проверял xml файл но и эффективно экстрактил из него данные

_Вместо_ того, чтобы данные хранить сразу же эффективно. Ну-ну...

>А какие езыги доступа к данным еще есть? Навигиционный способ? MUMPS

OQL, http://en.wikipedia.org/wiki/Object_Query_Language

булева логика, http://en.wikipedia.org/wiki/Logic_File_System

выбирай любой готовый

или составь свой собственный (если замыкание выдаёт GUID-адрес, выполняются условия вроде обычных ООБД, в контексте, в котором оно работает -- это язык запросов)