[devel] Что мне не нравится в alternatives

[devel] Что мне не нравится в alternatives

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 3570 bytes --]

Доброго времени суток.

Недавно в некоей дискуссии мне был задан вопрос: чем мне не
нравится alternatives в его существующем виде. Я несколько раз
брался размышлять на эту тему, прикидывал, что там можно, на
мой взгляд улучшить. Вдобавок, жизнь заставила залезть внутрь
программы с отладчиком. Попытаюсь здесь изложить то, что я надумал
в этой связи.

Без сомнения, новая утилита решает две проблемы, присущие
update-alternatives: практическую трудность восстановления
сломанной конфигурации и необходимость поддерживать
уникальные имена для конфигурируемых ссылок. Однако в предложенной
реализации обнаруживаются свои проблемы.

Хранить конфигурацию в XML-файлах -- неплохая идея сама по себе,
но надо иметь в виду, что имена файлов в POSIX и последовательности
символов в языке разметки XML -- вовсе не одно и то же. Чтобы ощутить
разницу, попробуйте создать альтернативы на ссылку, в имени которой
есть не-ASCII символы (допустим, если кодировка имен в файловой
системе KOI8-R). Libxml при разборе XML-файла конвертируёт
текст в UTF-8 независимо от исходной кодировки документа.
Можно представить, что имя файла побайтно корректно именно в исходной
кодировке документа, но это большая натяжка на семантику XML,
официально никак не поддерживается, да и с преобразованием обратно
в исходную кодировку будет геморрой. Я вижу надёжное, пусть и не очень
грациозное, решение -- кодировать в XML-конфигурации
имена файлов так же, как они кодируются в URL. Другое, менее надежное
решение -- иметь возможность указывать кодировку для имён файлов (не
как кодировку документа, а в виде специального атрибута в
конфигурации). Между прочим, эта проблема затрагивает все приложения, которые
представляют имена файлов в XML. 

По поводу реализации у меня тоже есть возражения.
Я уже говорил однажды, что схема кодирования имён ссылок имеет
недостатки. Во-первых, она без хорошего повода сужает набор символов,
которые можно использовать в именах, из-за того, что '/'
конвертируется в '|', а '|' не конвертируется ни во что. Несерьёзно.
Впрочем, это еще более академическая проблема, чем не-ASCII
символы в именах. Есть ещё неиспользованный потенциал для
более эффективного использования файловой системы и отсюда,
лучшей масштабируемости, если не изобретать никакого "манглинга",
а просто создавать в ссылочном каталоге структуру каталогов,
отображающую реальные имена файлов. Это потребует несколько
более трудоёмкой поддержки, зато позволит лучшим образом
ограничить неавторизованное получение информации о содержимом
каталогов (сейчас /etc/alternatives открыта всем даже
на чтение, но даже если выставить права 751, останется
возможность исследования по угаданным именам).   

Во время отладки заглянул в код разбора конфигурации. Недоумеваю. За
использованием разных вкусных плюшек из C++ скрывается то, что
называется wall-follower approach: все конфигурационные файлы
засасываются в память программы. Это обрамляется в один большой
XML-документ, который невозможно получить в физическом представлении,
не заглянув в код, кажется, библиотеки libing. Т.е. фактически
отдельные конфигурационные файлы могут быть даже не
well-formed XML-документами. После этого всё это разбирается в развесистое
дерево XML в памяти, из которого, насколько я понял, нужные вещи
вытягиваются с помощью XPath. У меня, конечно, Pentium 4 и достаточно
памяти, чтобы это работало пристойно. Но осадок остался.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
The longest part of the journey is said to be the passing of the gate.
		-- Marcus Terentius Varro

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Что мне не нравится в alternatives

[Stanislav Ievlev]

On Wed, Jan 07, 2004 at 08:49:03PM +0300, Mikhail Zabaluev wrote:
> Доброго времени суток.
> 
> Недавно в некоей дискуссии мне был задан вопрос: чем мне не
> нравится alternatives в его существующем виде. Я несколько раз
> брался размышлять на эту тему, прикидывал, что там можно, на
> мой взгляд улучшить. Вдобавок, жизнь заставила залезть внутрь
> программы с отладчиком. Попытаюсь здесь изложить то, что я надумал
> в этой связи.
Спасибо. Посмотрю и подумаю на досуге.
Некоторые вещи учту в новой версии которая ориентировочно в феврале/марте
появится в Дедале.
> 
> Без сомнения, новая утилита решает две проблемы, присущие
> update-alternatives: практическую трудность восстановления
> сломанной конфигурации и необходимость поддерживать
> уникальные имена для конфигурируемых ссылок. Однако в предложенной
> реализации обнаруживаются свои проблемы.
> 
> Хранить конфигурацию в XML-файлах -- неплохая идея сама по себе,
> но надо иметь в виду, что имена файлов в POSIX и последовательности
> символов в языке разметки XML -- вовсе не одно и то же. Чтобы ощутить
> разницу, попробуйте создать альтернативы на ссылку, в имени которой
> есть не-ASCII символы (допустим, если кодировка имен в файловой
> системе KOI8-R). Libxml при разборе XML-файла конвертируёт
> текст в UTF-8 независимо от исходной кодировки документа.
> Можно представить, что имя файла побайтно корректно именно в исходной
> кодировке документа, но это большая натяжка на семантику XML,
> официально никак не поддерживается, да и с преобразованием обратно
> в исходную кодировку будет геморрой. Я вижу надёжное, пусть и не очень
> грациозное, решение -- кодировать в XML-конфигурации
> имена файлов так же, как они кодируются в URL. Другое, менее надежное
> решение -- иметь возможность указывать кодировку для имён файлов (не
> как кодировку документа, а в виде специального атрибута в
> конфигурации). Между прочим, эта проблема затрагивает все приложения, которые
> представляют имена файлов в XML. 
> 
> По поводу реализации у меня тоже есть возражения.
> Я уже говорил однажды, что схема кодирования имён ссылок имеет
> недостатки. Во-первых, она без хорошего повода сужает набор символов,
> которые можно использовать в именах, из-за того, что '/'
> конвертируется в '|', а '|' не конвертируется ни во что. Несерьёзно.
> Впрочем, это еще более академическая проблема, чем не-ASCII
> символы в именах. Есть ещё неиспользованный потенциал для
> более эффективного использования файловой системы и отсюда,
> лучшей масштабируемости, если не изобретать никакого "манглинга",
> а просто создавать в ссылочном каталоге структуру каталогов,
> отображающую реальные имена файлов. Это потребует несколько
> более трудоёмкой поддержки, зато позволит лучшим образом
> ограничить неавторизованное получение информации о содержимом
> каталогов (сейчас /etc/alternatives открыта всем даже
> на чтение, но даже если выставить права 751, останется
> возможность исследования по угаданным именам).   
> 
> Во время отладки заглянул в код разбора конфигурации. Недоумеваю. За
> использованием разных вкусных плюшек из C++ скрывается то, что
> называется wall-follower approach: все конфигурационные файлы
> засасываются в память программы. Это обрамляется в один большой
> XML-документ, который невозможно получить в физическом представлении,
> не заглянув в код, кажется, библиотеки libing. Т.е. фактически
> отдельные конфигурационные файлы могут быть даже не
> well-formed XML-документами. После этого всё это разбирается в развесистое
> дерево XML в памяти, из которого, насколько я понял, нужные вещи
> вытягиваются с помощью XPath. У меня, конечно, Pentium 4 и достаточно
> памяти, чтобы это работало пристойно. Но осадок остался.
> 
> -- 
> Stay tuned,
>   MhZ                                     JID: mhz@altlinux.org
> ___________
> The longest part of the journey is said to be the passing of the gate.
> 		-- Marcus Terentius Varro



> _______________________________________________
> Devel mailing list
> Devel@altlinux.ru
> http://altlinux.ru/mailman/listinfo/devel

Re: [devel] Что мне не нравится в alternatives

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 2056 bytes --]

On Wed, 7 Jan 2004 20:49:03 +0300
Mikhail Zabaluev <mhz@altlinux.org> wrote:

> Доброго времени суток.
> 
> Недавно в некоей дискуссии мне был задан вопрос: чем мне не
> нравится alternatives в его существующем виде. Я несколько раз
> брался размышлять на эту тему, прикидывал, что там можно, на
> мой взгляд улучшить. Вдобавок, жизнь заставила залезть внутрь
> программы с отладчиком. Попытаюсь здесь изложить то, что я
> надумал в этой связи.
> 
> Без сомнения, новая утилита решает две проблемы, присущие
> update-alternatives: практическую трудность восстановления
> сломанной конфигурации и необходимость поддерживать
> уникальные имена для конфигурируемых ссылок. Однако в
> предложенной реализации обнаруживаются свои проблемы.
> 
> Хранить конфигурацию в XML-файлах -- неплохая идея сама по
> себе, но надо иметь в виду, что имена файлов в POSIX и
> последовательности символов в языке разметки XML -- вовсе не
> одно и то же. Чтобы ощутить разницу, попробуйте создать
> альтернативы на ссылку, в имени которой есть не-ASCII символы
> (допустим, если кодировка имен в файловой системе KOI8-R).
> Libxml при разборе XML-файла конвертируёт текст в UTF-8
> независимо от исходной кодировки документа. Можно представить,
> что имя файла побайтно корректно именно в исходной кодировке
> документа, но это большая натяжка на семантику XML, официально
> никак не поддерживается, да и с преобразованием обратно в
> исходную кодировку будет геморрой. Я вижу надёжное, пусть и не
> очень грациозное, решение -- кодировать в XML-конфигурации
> имена файлов так же, как они кодируются в URL. Другое, менее
> надежное решение -- иметь возможность указывать кодировку для
> имён файлов (не как кодировку документа, а в виде специального
> атрибута в конфигурации). Между прочим, эта проблема
> затрагивает все приложения, которые представляют имена файлов в
> XML.

Можно посмотреть на решение этой проблемы для @href в
спецификации HTML.

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: Что мне не нравится в alternatives

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

On Wed, 7 Jan 2004 20:49:03 +0300
Mikhail Zabaluev <mhz@altlinux.org> wrote:

<skipped/>

> well-formed XML-документами. После этого всё это разбирается в
> развесистое дерево XML в памяти, из которого, насколько я
> понял, нужные вещи вытягиваются с помощью XPath. У меня,
> конечно, Pentium 4 и достаточно памяти, чтобы это работало
> пристойно. Но осадок остался.

В рассылке libxml2 не так давно расхваливают новый супер-пупер
быстрый API - XMLReader, если я правильно помню.

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: Что мне не нравится в alternatives

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 1755 bytes --]

Hello Vitaly,

On Thu, Jan 08, 2004 at 09:11:19PM +0300, Vitaly Ostanin wrote:
>
> > Хранить конфигурацию в XML-файлах -- неплохая идея сама по
> > себе, но надо иметь в виду, что имена файлов в POSIX и
> > последовательности символов в языке разметки XML -- вовсе не
> > одно и то же. Чтобы ощутить разницу, попробуйте создать
> > альтернативы на ссылку, в имени которой есть не-ASCII символы
> > (допустим, если кодировка имен в файловой системе KOI8-R).
> > Libxml при разборе XML-файла конвертируёт текст в UTF-8
> > независимо от исходной кодировки документа. Можно представить,
> > что имя файла побайтно корректно именно в исходной кодировке
> > документа, но это большая натяжка на семантику XML, официально
> > никак не поддерживается, да и с преобразованием обратно в
> > исходную кодировку будет геморрой. Я вижу надёжное, пусть и не
> > очень грациозное, решение -- кодировать в XML-конфигурации
> > имена файлов так же, как они кодируются в URL. Другое, менее
> > надежное решение -- иметь возможность указывать кодировку для
> > имён файлов (не как кодировку документа, а в виде специального
> > атрибута в конфигурации). Между прочим, эта проблема
> > затрагивает все приложения, которые представляют имена файлов в
> > XML.
> 
> Можно посмотреть на решение этой проблемы для @href в
> спецификации HTML.

Я об этом же: URL кодируются именно чтобы избежать подобных проблем.
В принципе ничто не мешает объявить все имена файлов в существующих
конфигурациях закодированными по правилам URL, поскольку никто
ещё не смог/захотел выйти за пределы ASCII :) Главное, реальную
поддержку обеспечить.

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
Got a dictionary?  I want to know the meaning of life.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[devel] Re: Что мне не нравится в alternatives

[Mikhail Zabaluev]

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

Hello Vitaly,

On Thu, Jan 08, 2004 at 09:23:52PM +0300, Vitaly Ostanin wrote:
>
> В рассылке libxml2 не так давно расхваливают новый супер-пупер
> быстрый API - XMLReader, если я правильно помню.

Дело скорее не в используемых API из libxml (я не против построения
деревьев из отдельных файлов), а в том, что с данными
лучше работать в application-specific представлении и не закачивать
больше, чем необходимо для выполнения задачи, когда есть такая
возможность. В данном случае, файлики можно было бы разбирать
поочерёдно и непосредственно из файловых потоков, и по каждому
получать запись во внутренней структуре данных, каковыми записями
уже можно управлять эффективно (например, завести над ними map
по имени ссылки).

-- 
Stay tuned,
  MhZ                                     JID: mhz@altlinux.org
___________
When all other means of communication fail, try words.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]