From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Virus-Scanned: by cgpav Uf39PSi9pFi9oFi9 X-Virus-Scanned: amavisd-new at localhost Message-ID: <46E8D693.6000603@solin.spb.ru> Date: Thu, 13 Sep 2007 10:20:03 +0400 From: Aleksey Avdeev User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; ru-RU; rv:1.8.1.2pre) Gecko/20070119 SeaMonkey/1.1 MIME-Version: 1.0 To: ALT Devel discussion list X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: ALT Linux Sisyphus discussion list Subject: [devel] =?koi8-r?b?STogYWx0ZXJhdG9yLWFwYWNoZTI6INTFy9XdxcUg08/T?= =?koi8-r?b?1M/RzsnFIMkgxMHM2M7FytvFxSDSwdrXydTJxS4=?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2007 06:35:07 -0000 Archived-At: List-Archive: List-Post: Приветствую. На днях планирую отправить в Сизиф alterator-apache2-2.3. Его отличие от текущей версии одно -- русскоязычный help (справка на других языках отсутствует). Тестирование на живом Кирилле (kirill@) подтвердило мои худшие опасения: чуда не произошло, и простому, незамутнённому, пользователю сей шедевр инженерной мысли лучше не давать. Основные причины следующие: 1. "Защита от дурака" отсутствует как класс: основное что умеет модуль -- _тупо_ подключать/отключать конфигурационные файлы расположенные в /etc/httpd2/conf/*-available/. Корректность полученной конфигурации он не проверяет никаким образом, и если файлы с конфликтующим содержимым оказываются подключенными одновременно -- httpd2 стартовать отказывается (и это его нормальное поведение). Способы опеделить причину отказа в данном модуле не предусмотрены. 2. Основная единица с которой происходит работа -- файл с какими-то настройками. И именно "с какими-то": оставаясь в рамках данного alterator`овского модуля узнать что именно содержится в данном конкретном файле не возможно (только по англаязычному комментарию, если он есть). 3. Отсутствие понятной для пользователя логической разбивки: на формах работающих с содержимым /etc/httpd2/conf/{sites,extra}-available -- сборная саланка из файлов выполняющих абсолютно различные задачи (но, зато, совпадающая с тем, что действительно содержится в данных каталогах). 4. Крайне невнятная система отображения текущего состояния данного конфига и способ перехода между ними. И я незнаю как это исправить -- тут матрица из 6 состояний: по одной оси (наличие линка в *-enabled) он может быть подключен/отключен, по другой (настройка через *-start.d) он может быть подключаем/отключаем/ненастроен... Как это отобразить в интерфейсе _понятным_ для пользователя образом -- ХЗ... 5. Отсутствие локализации служебных человекочитабельных полей, считанных из конфигов. Т. е. содержимое служебного коментария Summary, считанного из конфига (осли он там есть) выдаётся пользователю без перевода... И такое у меня по всему интерфейсу (пара форм без основной массы вышеперечисленного погоды не делают)... :-( Путей борьбы за светлое будущее видно 2: 1. Всю логику управления сервером прошить в alterator-apache2 жестким образом. В модуль придётся прописывать имена конкретных конфигурационных файлов и в нём-же -- учитывать логические связи между ними... 2. Внести в конфигурационные файлы метоинформацию о их типовом назначении и взаимосвязях между ними (как миниум -- прописать конфликты). Логику и интерфейс alterator-apache2 строить уже с опорой на данную метоиныормацию. Путь 1 мне не нравится: движение по ниму приведёт к "толстому" и достаточно монолитному alterator-apache2 который будет жёстко завязан на конфигурационные файлы apache2 конкретных сборок. При каждом изменении состава конфигов (а он будет меняться) -- его прдётся корректировать по новой. Как я буду это дело поддерживать -- предстовляю слабо. Путь 2, с моей точки зрения, выглядит более переспективным, т. к.: а) Позволит вынести часть логики (контроль конфликтов, как миниум) на уровень утилит a2*, непосредственно этими конфигами управляющих (что как раз и закроет часть проблем с ними связанных). б) Позволит писать alterator-apache2 орентируясь уже на типы конфигов, а не на их имена. Это даст большую свободу манёвра и позволит ослабить связь между alterator-apache2 и конфигурационными файлами конкретных сборок apache2 (т. к. контролировать пофайловое соответствие уже непридётся). в) Позволит выполнять эту работу не только мне (за счёт того, что я смогу формализовать требования к конфигам, с которыми сможет работать модуль). :-) Вот такие пироги с котятами... Прошу высказываться. PS: Прошу отвечать в одну рассылку, по возможности. -- С уважением. Алексей.