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

[Mikhail Zabaluev]

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

Недавно в некоей дискуссии мне был задан вопрос: чем мне не
нравится 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
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20040107/b29590ec/attachment-0001.bin>