Система распространения и установки - XPInstall

17.2. По направлению к удаленной установке

Вообще, удаленная установка - это метод распространения информации, подобный издательской модели традиционных медиа. Создать комплект приложения для удаленной установки через web - значит стать издателем.

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

Удаленная установка основана на использовании URL. Система удаленной установки Mozilla может задействовать схему "file:" так же легко, как и схему "http:". Таким образом, все сделанные здесь замечания относятся и к локальной установке.

17.2.1. Что делает программист

Здесь мы опишем задачи, которые должен выполнить программист, чтобы приложение могло быть установлено пользователем по сети. Система установки может разрабатываться одновременно с другими задачами, стоящими перед разработчиком.

17.2.1.1. Присваивание имен и версий

Первый шаг - присвоить приложению необходимые имена. Для работы XPInstall требуется несколько имен.

Эти имена включают: текстовое имя (описание), имя пакета, имя приложения в регистре и версию. Также требуются платформо-зависимые имена. На платформе Microsoft Windows полезен ключ регистра (registry key). Могут понадобиться Macintosh Aliases и Microsoft Windows Shortcuts. Всем этим именам, кроме версии, желательно иметь один и тот же корень. Корень - это просто слово, из которого образуются другие слова. Иные маркеры, такие как броские заголовки (mastheads), бренды, имена исполняемых файлов командной строки, системой XPInstall в явном виде не поддерживаются. XPInstall также не поддерживает и графическое представление приложения, например иконки.

Текстовое имя - это юникодная строка, появляющаяся в диалоговом окне, которое система XPInstall показывает пользователю. Поскольку это юникод, он может содержать среди прочих и символы , или TM. XPInstall показывает эту строку латиницей, слева направо, что может являться ограничением для некоторых языков. Вот пример текстового имени:

Frederick's Amazing Shopping Spree System, Gold Version

Имя пакета - это имя, под которым приложение будет установлено в chrome(в случае, если оно устанавливается в chrome). Это имя в кодировке 8-bit extended ASCII, и, для абсолютной переносимости, оно должно быть длиной 8 алфавитно-цифровых символов или меньше (для Unix 14 символов). Поскольку оно используется как имя директории, оно не должно содержать никаких знаков пунктуации (может быть, за исключением знака подчеркивания). Номер версии не нужно включать в имя пакета (например, netscape7), кроме того случая, когда требуется установить две разные версии одного и того же пакета одновременно. Если приложение устанавливается не в chrome, то имя директории для установки должно иметь те же ограничения, что и имя пакета. Пример имени пакета:

fredshop

Имя приложения в регистре - это имя, используемое Mozilla для управления приложением на локальном хосте. Оно используется для управления версиями, установкой и удалением приложения. Регистры Mozilla описываются ниже, в разделе "Технологии установки". Имя регистра выглядит как путь в Unix, за исключением того, что может содержать юникодные символы. Внутри регистра оно хранится в UTF8. Большинство имен регистра следуют такой конвенции:

/Application Publisher/short-name/subproduct

Application Publisher может быть корпоративным или техническим именем. Корпоративное имя может выглядеть как "Alpha Trading Company". Техническое имя может следовать системе, принятой для пакетов Java, например "mozilla.org". Сокращение - это часть имени приложения и обычно оно подобно имени пакета (например, Navigator). Часть subproduct опциональна и используется, когда приложение - часть набора утилит, каждая из которых является фрагментом большого приложения. Пример из Mozilla:

/mozilla.org/Mozilla/JavaScript Debugger/Venkman Chrome

Данный пример показывает, что подраздел может в свою очередь ветвиться. Venkman Chrome - это часть JavaScript Debugger, который в свою очередь - часть Mozilla, собственно приложения.

Если слеша "/" в имени регистра нет, оставшаяся часть рассматривается как подпуть и к ней будет добавлен префикс /mozilla.org/Mozilla/.

Фактически, имя приложения в регистре может быть любым путем, части которого разделены прямым слешем; у первой из последовательности частей нет явно определяемого значения. Это имя не должно соответствовать имени директории; это просто иерархический ключ в стиле ключей Windows Registry. Он имеет ограничение по длине в 2000 символов. Пример:

/Fred's Pyramid Company/Amazing Shopping Spree System/
 Gold Version

Версии приложений Mozilla имеют фиксированный формат; это номер, состоящий из четырех частей. Это четыре 32-битных целых, или строка целых, разделенных точками. Эта строка должна легко конвертироваться в четыре целых числа, она не должна содержать слова "beta" или другой бессмыслицы. Строка версии имеет следующий формат:

"{major}.{minor}.{revision}.{build}"

Главное число (major number) получает значение 0 и может изменяться, если дизайн приложения значительно изменится.

Подчиненное число также получает значение 0 и его увеличение отражает появление в приложении новых свойств. Приложения с меньшим подчиненным числом должны взаимодействовать с данной версией.

"Ревизия" также начинается с 0 и обычно увеличивается при исправлениях ошибок и простейших изменениях. За исключением этих исправлений, все более ранние ревизии должны вести себя идентично данной. "Билд" отражает конкретную попытку собрать приложение из исходного кода. Обычно порождается в процессе сборки и представляет собой уникальный ключ особого типа. Пример полного номера версии:

"1.0.2.20021018"

Существует несколько необязательных конвенций, связанных с этими номерами. Вот некоторые их них:

Номер билда точно идентифицирует каждую конкретную компиляцию или сборку пакета. Это может быть последовательно увеличивающееся число или дата. 32-битное число является достаточно большим, чтобы содержать уникальную последовательность цифр даты, по крайней мере, до 2200 года. Например, для даты 9 A.M., 28 февраля 2003 года соответствующее число будет 2003022809. Эту систему построения билда использует Mozilla.

Ядро Linux и некоторые другие продукты используют четные подчиненные (minor) числа для обозначения стабильных релизов, а нечетные - для инновационных. Mozilla не использует эту систему.

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

17.2.1.2. Создавая мир

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

Итак, второй шаг в подготовке распространения приложения по сети - общая подготовка выпуска приложения (a release review). Чтобы стратегия распространения приложения сработала чисто, инженер, готовящий приложение, должен очень отчетливо понимать, что, собственно, распространяется и куда. Это значит - нужно определить информацию о конфигурации приложения. Документ README, поставляемый вместе с браузером Mozilla, служит примером такой информации, но нужно мыслить и дальше в том же направлении. Необходимо определить три ключевых позиции: исходники (baseline), воздействие (footprint) и требования.

Исходники - самое начало создания распространяемого xpi-комплекта. Это может быть просто собрание всех исходных файлов на неперезаписываемом CD-R. Или это может быть CVS-тег, автоматически готовящий стандартный набор исходников приложения. Если не удается вновь и вновь создать тот же самый исходный распространяемый комплект файлов, вы не сможете тестировать приложение корректно, и не сможете распространять впоследствии патчи. Если ваше приложение распространяется под одной из свободных лицензий, то сама лицензия требует, чтобы вы могли предоставить пользователю исходники, и сделали их доступными для всех.

Для простых приложений следует просто сделать резервную копию перед каждым релизом.

Воздействие (footprint) - то, как ваше приложение отразится на пользовательском компьютере. Это как минимум список всех файлов, которые будут изменены установленным приложением. Цель выявления воздействия - определить любое место на компьютере, изменяемое установленным или работающим приложением. Когда пользователь номер 52345 звонит, обеспокоенный поломкой компьютера, этот список поможет локализовать проблему.

Примерами обычных элементов воздействия могут быть регистр Windows, иконки на рабочем столе, переменные окружения, глобальные MIME-типы, инсталляционные скрипты. Внутри самой Mozilla работающее приложение может изменять файлы настроек, установки безопасности и локальные MIME-типы. Приложения могут добавлять компоненты в директорию компонентов Mozilla, добавлять специальные бинарные утилиты или модифицировать скрипты командной оболочки, используемые для старта платформы.

Если установочный XPI-комплект затрагивает области вне установочной зоны платформы, не следует автоматически все сваливать под C:\Program Files (Windows) или /usr (UNIX). Это нарушит работу тех IT- специалистов, которые отвечают за конфигурирование и управление системой. Удостоверьтесь, что ваше приложение установит все в одну- единственную папку с именем, выбранным пользователем. Никогда не следует устанавливать файлы в /etc или C:\Windows или C:\Winnt, если есть способ этого избежать.

Для простых приложений воздействие не должно простираться дальше директории chrome и регистров Mozilla. Если пользователь пожелает поместить файлы, генерируемые платформой, куда-либо еще, то это его трудности.

Наконец, требования - это описание компьютерной системы, для которой приложение предназначено. Эти требования включают описание "железа", операционной системы, уже существующих приложений, специфических файлов и конфигураций, требуемого дискового пространства - всего, что необходимо. Описание требований - основа файла README, который пользователь должен получить. Его используют также для определения списка тех проверок, которые должен выполнить инсталляционный скрипт.

Для простых кроссплатформенных приложений требования - не более чем минимальная версия платформы Mozilla.