Опубликован: 10.12.2007 | Доступ: свободный | Студентов: 808 / 17 | Оценка: 5.00 / 5.00 | Длительность: 58:33:00
Лекция 16:

Объекты XPCOM

16.4.5. Объекты стека Web-протоколов

Протокол HTTP, лежащий в основе стека Web-протоколов, широко применяется в Mozilla. Скрипты могут работать с ним различными способами, включая непосредственное использование объекта AOM XMLHttpRequest. Работа с прочими протоколами, поддерживаемыми Mozilla, требует применения специализированных объектов.

Документация по использованию Web-протоколов в Mozilla доступна по адресу http://www.mozilla.org/xmlextras/.

XML-RPC представляет собой простейшую надстройку над HTTP. Следующая пара XPCOM используется для формирования фрагмента XML, содержащего запрос RPC, его синхронную или асинхронную передачу по указанному URL с помощью HTTP, а также возвращение результатов или сообщений об ошибках:

@mozilla.org/xml-rpc/client;1 nsIXmlRpcClient

Сообщения об ошибках возвращаются в виде объектов с интерфейсом nsIXmlRpcFault.

При использовании традиционного RPC применяется утилита rpcgen(1) или другие аналогичные инструменты, которые генерируют код на языке C для удаленного вызова процедуры. Этот код:

  • Преобразует собственные типы платформы в переносимые типы RPC.
  • Упаковывает вызовы RPC в кроссплатформенный формат XDR/NDR для передачи по сети.
  • Управляет передачей данных по сети и работает с временными задержками.
  • Выполняет перечисленные задачи достаточно эффективно.

Особенность использования XML-RPC на платформе Mozilla состоит в том, что JavaScript является интерпретируемым языком, а код платформы, работающий с удаленным вызовом процедур, как правило, уже скомпилирован. Поэтому порядок работы с RPC отличается от традиционного подхода. Объект nsIXmlRpcClient упаковывает вызовы XML-RPC в переносимый XML, но передачу вызова и получение результата он делегирует объекту канала. Поэтому для управления задержками или получения информации о них необходимо обращаться именно к объекту канала. Задача преобразования типов JavaScript в переносимые типы XML-RPC оставлена разработчику приложения. Объект nsIXmlRpcClient предоставляет ряд методов-фабрик для создания типов XML-RPC, однако разработчик должен воспользоваться этими методами самостоятельно. Наконец, этот объект реализован на JavaScript и постоянно обращается к объекту window.Components для разрешения имен, что ограничивает его производительность.

Протокол SOAP, разработанный как замена XML-RPC, постепенно приобретает все большую популярность. SOAP – сложная технология, которая заслуживает отдельной книги. Здесь представлены лишь минимально необходимые сведения для работы с этим протоколом. Полезным источником информации являются спецификации SOAP и XML-P, принятые Консорциумом WWW. В будущем технология SOAP будет официально называться XML-P (P означает "протокол"), хотя популярное сокращение SOAP вряд ли выйдет из употребления.

Вызов SOAP представляет собой сообщение-запрос, за которым следует сообщение-ответ, поэтому HTTP является естественным транспортным протоколом для SOAP. Оба сообщения имеют формат XML. Оба сообщения состоят из тега-контейнера, содержащего один необязательный тег-заголовок и один обязательный тег, представляющий тело запроса. Эти теги описаны в спецификации SOAP. Тело запроса содержит фрагмент документа, состоящего из других тегов. Они определяются разработчиком приложения, который должен создать для них формальное определение (схему) или использовать существующую схему. Эти теги представляют отправляемые и возвращаемые данные.

Для того чтобы разработчик мог создать сообщение SOAP, необходимы объекты, выполняющие следующие задачи:

  • Работа с определениями схем XML (XML Schema)
  • Создание контейнеров SOAP и их внутренней структуры
  • Установление соединения с сервером, поддерживающим SOAP
  • Отправление запроса SOAP
  • Обработка любых исключительных ситуаций и ошибок
  • Извлечение возвращаемого XML-документа

Ниже перечислены пары XPCOM для создания объектов, соответствующих каждой из задач:

  • @mozilla.org/xmlextras/schemas/schemaloader;1 nsISchemaLoader
  • @mozilla.org/xmlextras/soap/call;1 nsISOAPMessage
  • @mozilla.org/xmlextras/soap/transport;1?protocol=http;nsISOAPTransport
  • @mozilla.org/xmlextras/soap/call;1 nsISOAPCall
  • @mozilla.org/xmlextras/soap/fault;1 nsISOAPFault
  • @mozilla.org/xmlextras/soap/response;1 nsISOAPMessage

Помимо этих объектов, обеспечивающих базовую функциональность для работы с SOAP, существует множество вспомогательных и второстепенных интерфейсов. Наконец, для работы с протоколом необходим сервер, способный принимать запросы SOAP по протоколу HTTP и отвечать на них.

Интерфейс nsISOAPMessage также доступен в форме объекта AOM SOAPCall, создать который очень просто:

var soap_call = new SOAPCall();

Аналогичным образом интерфейсу nsISOAPParameter соответствует объект AOM SOAPParameter. Эти два объекта позволяют выполнять простые вызовы SOAP, не прибегая к сложным подготовительным операциям.

Широко известен сервис SOAP, позволяющий делать запросы к поисковой машине Google. Этот сервис может использоваться для отладки SOAP-клиентов на платформе Mozilla. Описание его программного интерфейса доступно по адресу http://www.google.com/apis/. Однако отладка сетевых клиентов может быть гораздо более эффективной в том случае, когда разработчик контролирует не только клиент, но и сервер. Подходящее решение входит в состав исходного кода платформы. Фрагмент кода, доступный по следующему адресу, может использоваться для изучения SOAP и отладки клиентов:

http://lxr.mozilla.org/seamonkey/source/extensions/xmlextras/tests/

В этом каталоге находятся три небольших программы на языке Perl, которые могут получать SOAP-запросы и отвечать на них. Для этого их нужно установить на Web-сервер как CGI-скрипты. Скрипт echo.cgi реализует операцию "ping", которую, по соглашению, должен поддерживать всякий SOAP-сервер. Два других скрипта возвращают сообщение об успешном выполнении запроса и сообщение об ошибке соответственно. Сообщение об успешном выполнении включает также возвращаемые данные.

Поддержка SOAP в Mozilla достаточна для того, чтобы платформа могла выступать в качестве не только клиента, но и SOAP-сервера. Однако в настоящее время для этого необходимо, чтобы все клиенты использовали одно и то же транспортное соединение (один сокет или дескриптор файла). Поэтому пока на основе Mozilla невозможно реализовать сервер, который мог бы принимать SOAP-запросы с любого узла Internet.

Последний протокол стека Web-протоколов, поддерживаемый Mozilla, – WSDL, язык описания Web-сервисов. Этот протокол объединяет группу отдельных вызовов SOAP в единый документ-определение. В некотором смысле такое определение аналогично файлу IDL в архитектуре CORBA или файлу XPIDL в Mozilla. Создание определений WSDL является обязанностью разработчика приложения.

Поддержка WSDL появилась в Mozilla незадолго до написания этой книги, и интерфейсы еще не успели устояться. Наилучшим источником актуальной информации о поддержке WSDL является следующий документ, который содержит XPIDL-определения интерфейсов для работы с WSDL:

http://lxr.mozilla.org/seamonkey/source/extensions/xmlextras/wsdl/

Чтобы узнать идентификаторы контрактов (Contract ID) компонентов, реализующих эти интерфейсы, следует просмотреть заголовочные файлы (с расширением .h) в этом каталоге или использовать утилиту для просмотра компонентов (Component Viewer). В последнем случае нужно указать следующий префикс для Contract ID:

@mozilla.org/xmlextras/wsdl/

Полная поддержка WSDL реализована в версиях Mozilla начиная с 1.4.

16.4.6. Пакетная обработка XSLT

Для обращения к системе обработки XSLT из скриптов JavaScript используется следующая пара XPCOM:

@mozilla.org/document-transformer;1?type=text/xsl nsIXSLTProcessor

Объект с таким интерфейсом принимает в качестве аргументов два дерева или поддерева DOM. Первое из них образовано командами XSLT, а второе представляет собой документ, который должен быть преобразован. Результатом обработки является третье дерево или поддерево. Кроме того, объекту могут быть переданы различные параметры преобразования. Система не может преобразовывать документы "на месте" – чтобы работать с полученным документом, его необходимо присоединить к существующей иерархии DOM.

16.5. Конфигурация платформы

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

16.5.1. Управление кэшем

Предполагается, что кэш браузера Mozilla прозрачен для любых действий по получению Web-документов, однако при необходимости с ним можно взаимодействовать. Кэш используется для любых запросов к URL, выполняемых платформой, если в явном виде не было указано избегать использования кэша или отключить его. Доступ к кэшу на низком уровне осуществляется при помощи следующей пары XPCOM:

@mozilla.org/network/cache-service;1 nsICacheService

Объект, полученный таким образом, должен иметь доступ к константам, предоставляемым интерфейсом nsICache. Техника работы с кэшем на низком уровне является неожиданно сложной в силу используемой модели блокировки, которая допускает несколько одновременных сеансов чтения, но лишь один сеанс записи. Это означает, что попытка работы с кэшем на низком уровне может оказаться неудачной по причине конфликта из-за доступа к ресурсам. Разработчику приложений проще не иметь дела с этими тонкостями и использовать сервисы более высокого уровня, например транспорты и каналы, которые взаимодействуют с кэшем автоматически. Однако указанный интерфейс предоставляет и ряд методов, полезных для разработчика приложений, например evictEntries(), который может использоваться для очистки кэша.

Очень простое применение кэша – упреждающая загрузка документов. Такая загрузка подразумевает помещение документа в кэш без обязательного отображения или какой-либо обработки. Упреждающая загрузка может выполняться лишь для URL с префиксом http:, которые не являются запросами GET (не имеют части вида ?param= ). Для упреждающей загрузки используется следующая пара XPCOM:

@mozilla.org/prefetch-service;1 nsIPrefetchService

Аналогичная функциональность с возможностью более детального управления доступна при помощи интерфейса nsIRequest, который является основой для каналов и транспортов. Свойство loadFlags, которое может устанавливаться для каждого URI по отдельности, определяет, каким образом полученный документ взаимодействует с кэшем.

16.5.2. Каталог файловой системы

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

Каталоги (службы каталогов) Mozilla подобны телефонной книге – они позволяют получить информацию об объекте или ресурсе по его имени. В принципе, каталоги не привязаны к концепции файловой системы – в составе платформы существует целый ряд различных каталогов. Некоторые из них обеспечивают доступ к удаленным ресурсам, другие, например Адресная книга Mozilla, – к данным, хранящимся на локальном диске, третьи – к различным структурам и объектам платформы, находящимся в памяти. Один из этих каталогов содержит пути к файлам и папкам, важным для работы платформы. Это единственная служба каталогов, которая обсуждается далее в данном разделе.

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

Эта служба каталогов, называемая каталогом файловой системы, доступна при помощи следующей пары XPCOM:

@mozilla.org/file/directory_service;1 nsIDirectoryService

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

Интерфейс nsIDirectoryService не слишком полезен сам по себе. Его роль состоит в управлении объектами-источниками (providers). Источник представляет собой объект, который предоставляет службе каталогов часть ее содержимого. В обычной ситуации объект службы каталогов вообще не имеет собственного содержимого. Вместо этого в нем зарегистрированы ноль или более источников, содержимое которых доступно при помощи службы каталогов. Каждый источник поддерживает интерфейс nsIDirectoryServiceProvider. Когда скрипт обращается с запросом к службе каталогов, объект службы просматривает все зарегистрированные источники в поисках запрошенных данных. В такой ситуации источники полностью скрыты от скрипта, обращающегося к каталогу.

Помимо источников, служба каталогов Mozilla использует и другие интерфейсы. Так, nsIProperties – стандартный интерфейс, позволяющий получить по имени объекта данные о нем, хранящиеся в каталоге. Нужное имя (фактически, псевдоним искомого объекта) передается службе каталогов при помощи метода get() интерфейса nsIProperties. В результате будет возвращен любой объект (запись в каталоге), имя которого соответствует переданному псевдониму. Как и другие службы каталогов Mozilla, каталог файловой системы поддерживает этот интерфейс. Пример его использования приведен в листинге 16.7:

var Cc = Components.classes;
var Ci = Components.interfaces;

var dir = Cc["@mozilla.org/file/directory_service;1"];
dir = dir.getService(Ci.nsIDirectoryService); // Инициализация

// Поместите сюда обращения к dir.registerProvider(provider_object)

var dir_props = dir.QueryInterface(Ci.nsIProperties);

var file = dir_props.get("myalias", Ci.nsIFile);

if (file == null )
  alert("Нет такого ресурса");
Листинг 16.7. Получение ресурса из каталога файловой системы с использованием псевдонима

Этот код создает объект службы каталогов, не добавляя к нему никаких источников, затем получает интерфейс nsIProperties и запрашивает из каталога данные для псевдонима "myalias". Поскольку каталог файловой системы XPCOM содержит информацию о файлах и папках, ожидается, что будет возвращен объект, поддерживающий интерфейс nsIFile.

В данном примере объект не будет найден в каталоге, и система выдаст предупреждение (последняя строка кода). Это произойдет по двум причинам. Во-первых, строка "myalias" в рамках платформы Mozilla не определена в качестве псевдонима известных файла или папки. Это легко исправить – достаточно использовать какой-либо известный псевдоним. Однако есть и более серьезная проблема – к объекту службы каталогов не было добавлено ни одного источника. Поэтому мы могли бы ожидать, что в данном коде не будут распознаваться никакие псевдонимы. Однако это не так. На практике, к объекту каталога файловой системы всегда подключено, как минимум, два источника.

  • Первый из этих источников автоматически добавляется к объекту каталога в момент создания последнего. Данный источник добавляет к каталогу псевдонимы уровня приложения. Эти псевдонимы соответствуют папкам и файлам в той области файловой системы, где установлена платформа Mozilla.
  • Второй источник создается при запуске платформы. Этот источник связан с профилем текущего пользователя, он добавляет к каталогу псевдонимы для файлов и папок, связанных с этим профилем.
  • Наконец, если платформа отображает Web-страницу, и эта страница содержит объект, отображаемый при помощи подключаемого модуля (plugin), например апплет Java, к каталогу будет добавлен третий источник, но лишь на то время, пока отображается страница. Этот источник, связанный с менеджером модулей, добавляет к каталогу псевдонимы, специфичные для модулей. Как описано ниже, эти псевдонимы обрабатываются не так, как остальные, тем не менее, каталог возвращает соответствующий им файловый объект, если таковой существует.

Дополнительную сложность работе со службой каталогов придает тот факт, что объект, который представляет каталог файловой системы, одновременно реализует интерфейс источника. Этот источник определяется следующей парой XPCOM:

@mozilla.org/file/directory_service;1 nsIDirectoryServiceProvider

Такой источник представляет собой дополнение к трем, перечисленным выше. Его редко регистрируют в каких-либо службах каталогов. Вместо этого к нему обращаются непосредственно из скриптов – в отличие от остальных источников, он не является скрытым. Этот источник добавляет псевдонимы, важные для системы XPCOM, которая составляет основу платформы Mozilla. Эти псевдонимы представляют файлы и папки, необходимые для задач самого низкого уровня; местонахождение многих из них зависит от операционной системы.

Пример непосредственной работы с этим источником приведен в листинге 16.8.

var Cc = Components.classes;
var Ci = Components.interfaces;

var prov = Cc["@mozilla.org/file/directory_service;1"];
prov = prov.getService(Ci.nsIDirectoryServiceProvider);

var result = {}; // пустой объект
var file = prov.getFile("alias", result);

if ( file == null ) alert("Нет такого ресурса");

// alert(result.value)
Листинг 16.8. Получение файлового ресурса из источника с использованием псевдонима

Поскольку обычно источники управляются объектом, представляющим службу каталогов, аргументы метода getFile() приспособлены для использования с таким объектом. Второй аргумент этого метода, пустой объект, позволяет источнику передать службе каталогов определенную информацию о состоянии ресурса. Как правило, обычному скрипту эта информация не нужна, если только он не реализует собственную службу каталогов. Дальнейшую информацию по этому вопросу можно получить в файле XPIDL для интерфейса nsIDirectoryServiceProvider.

В оставшейся части раздела перечисляются псевдонимы, поддерживаемые названными источниками. Мы начнем с последнего, специализированного источника.

16.5.2.1. Псевдонимы файловой системы XPCOM

Эти псевдонимы поддерживаются специализированным источником, встроенным в объект службы каталогов. Как правило, с этим источником работают непосредственно из скриптов. Псевдонимы перечислены в таблицах 16.13 – 16.16. Таблица 16.13 относится ко всем платформам.

Таблица 16.13. Псевдонимы файловой системы XPCOM для всех платформ
Псевдоним Описание соответствующего nsIFile
ComRegF Реестр компонентов XPCOM – не используется
ComsD Папка, содержащая компоненты XPCOM
CurProcD Папка с исполняемым файлом текущего процесса, в UNIX всегда определяется переменной окружения $MOZILLA_FIVE_HOME
CurWorkD Папка, которая является текущим рабочим каталогом исполняемого файла
DrvD Корень файловой системы операционной системы – в Windows обычно C:; в UNIX: /; в MacOS: корневой том
GreComsD Папка, содержащая компоненты XPCOM, относящиеся к GRE (Gecko Runtime Engine)
GreD Папка, в которой установлен GRE
Home Домашняя папка (каталог) текущего пользователя – в Windows: %HOME%; в UNIX: $HOME; в MacOS: папка документов
TmpD Папка операционной системы для хранения временных файлов – в Windows: %TMP%; в UNIX: $TMP; в MacOS: папка временных файлов

В таблице 16.14 перечислены псевдонимы, которые поддерживаются только в системе Microsoft Windows. Константы CSIDL, приведенные в таблице, являются частью программного интерфейса (API) Microsoft Windows и используются в таких функциях Windows, как, например, SHGetFolderPath(). Каждый псевдоним соответствует известной папке. Полное описание этих констант приведено в документе по адресу:

http://msdn.microsoft.com/library/en-us/shellcc/platform/shell/reference/enums/csidl.asp

Таблица 16.14. Псевдонимы файловой системы XPCOM, поддерживаемые только в системе Microsoft Windows
Псевдоним Эквивалентная константа CSIDL Псевдоним Эквивалентная константа CSIDL
AppData CSIDL_APPDATA netH CSIDL_NETHOOD
Buckt CSIDL_BITBUCKET NetW CSIDL_NETWORK
CmDeskP CSIDL_COMMON_DESKTOPDIRECTORY Pers CSIDL_PERSONAL
CmPrgs CSIDL_COMMON_PROGRAMS PrntHd CSIDL_PRINTHOOD
CmStrt CSIDL_COMMON_STARTUP Prnts CSIDL_PRINTERS
Cntls CSIDL_CONTROLS Progs CSIDL_PROGRAMS
DeskP CSIDL_DESKTOPDIRECTORY Rcnt CSIDL_RECENT
DeskV CSIDL_DESKTOP SndTo CSIDL_SENDTO
Drivs CSIDL_DRIVES Tmpls CSIDL_TEMPLATES
Favs CSIDL_FAVORATES WinD CSIDL_WINDOWS

Нужно иметь в виду, что использование псевдонимов с префиксом Cm в однопользовательских версиях Windows, например Microsoft Windows 98, приводит к возникновению исключительной ситуации.

В таблице 16.15 приведены псевдонимы, поддерживаемые только на платформе Macintosh. Прочие псевдонимы перечислены в таблице 16.16. Псевдонимы, поддерживаемые в таких системах, как OS/2, BeOS, OpenVMS и т.д., в этой книге не приводятся.

Таблица 16.15. Псевдонимы файловой системы XPCOM, поддерживаемые только на платформе Macintosh
Псевдоним Папка Псевдоним Папка
ApplMenu Меню (Apple Menu) Exts Папка расширений (Extensions folder)
ClassicPrfs Папка профиля Mac Classic Isrch Папка поиска в Internet
CntlPnl Панель управления Prfs Папка настроек (Preferences folder)
DfltDwnld Папка загрузок по умолчанию (Default Download folder) Shdwn Папка отключения (Shutdown folder)
Docs Папка документов Trsh Папка мусорной корзины
Desk Папка рабочего стола
Таблица 16.16. Различные псевдонимы файловой системы XPCOM
Псевдоним Описание соответствующего nsIFile
Fnts Macintosh и Microsoft Windows: папка, содержащая системные шрифты
LibD UNIX: /usr/local/lib/netscape
Locl UNIX: /usr/local/netscape
Strt Macintosh и Microsoft Windows: папка запуска ("Автозагрузка")
SysD Только Macintosh OSX: системная папка
UlibDir Только Macintosh OSX: /usr/lib
16.5.2.2. Псевдонимы файловой системы прикладного уровня

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

Платформа Mozilla не сводится к системе XPCOM. Последняя образует ядро платформы, поверх которого реализовано множество компонентов и инфраструктура, также составляющие часть платформы. В состав платформы входят папки, в которые установлены браузеры и другие продукты, система chrome, кэши, реестры и т.д. Их местонахождение определяется псевдонимами прикладного уровня, которые перечислены в таблице 16.17.

Таблица 16.17. Псевдонимы файловой системы прикладного уровня.
Псевдоним Соответствующий объект Путь относительно папки установки
AppRegF Файл глобального реестра приложений Расположен в другом месте (см. "Система распространения и установки - XPInstall" "Развертывание")
AppRegD Папка, содержащая глобальный реестр приложений Расположена в другом месте (см. "Система распространения и установки - XPInstall" "Развертывание")
DefRt Папка верхнего уровня для параметров по умолчанию Defaults
PrfDef Папка, содержащая настройки по умолчанию Defaults/pref
profDef Папка, содержащая параметры профиля по умолчанию для текущих параметров локализации Defaults/profile/{locale}
ProfDefNoLoc Папка, содержащая параметры профиля по умолчанию для параметров локализации по умолчанию Defaults/profile
DefProtRt Папка верхнего уровня для пользовательских профилей Расположена в другом месте (см. ниже)
Ares Папка ресурсов Res
Achrom Папка chrome Chrome
SrchPlugns Папка модулей поиска Searchplugins
ApluginsDL Список доступных подключаемых модулей (возвращает интерфейс nsIEnumerator ) Plugins/*
XPIClnupD Папка, содержащая программы для удаления приложений Uninstall
UserPlugins Папка в составе профиля текущего пользователя, содержащая установленные модули уровня пользователя Расположена в другом месте
OSXUserPlugins Папка, содержащая пользовательские модули (только MacOS X) Расположена в другом месте
OSXLocalPlugins Папка, содержащая локальные модули (только MacOS X) Расположена в другом месте
MacSysPlugins Папка, содержащая системные модули (только Mac Classic) Расположена в другом месте

Псевдоним DefProtRt возвращает следующие значения в зависимости от платформы:

  • UNIX: ~/.mozilla
  • Windows: {CLSID_APPDATA}\Mozilla\Profiles
  • Macintosh: :Documents:Mozilla:Profiles
16.5.2.3 Псевдонимы файловой системы уровня профиля пользователя

Эти псевдонимы предоставляются источником, который подключается к службе каталогов в момент запуска платформы. В полном дистрибутиве платформы (который не был специально "облегчен" с какой-либо целью, например, для использования в мобильных устройствах) они доступны всегда. Псевдонимы перечислены в таблице 16.18; они одинаковы для всех платформ.

Таблица 16.18. Псевдонимы файловой системы уровня профиля пользователя
Псевдоним Объект Путь относительно папки профиля пользователя
PrefD Папка, содержащая файл пользовательских настроек; совпадает с ProfD -
PrefF Файл пользовательских настроек prefs.js
ProfD Корневая папка текущего профиля -
Uchrm Папка, содержащая данные chrome уровня пользователя chrome
LclSt Файл конфигурации окон Mozilla для данного пользователя localstore.rdf
Uhist Файл истории посещений классического браузера history.dat
Upanels Файл вкладок для боковой панели классического браузера, определяемых пользователем panels.rdf
UmimTyp Информация о типах MIME для всех приложений платформы mimeTypes.rdf
Bmarks Файл закладок классического браузера bookmarks.html
Dloads Файл истории загрузок классического браузера downloads.rdf
SrchF Файл конфигурации поисковой машины классического браузера search.rdf
MailD Папка, содержащая данные локальных почтовых ящиков Mail
ImapMD Папка, содержащая данные учетных записей IMAP ImapMail
NewsD Папка, содержащая информацию о конференциях News
MFCaD Файл, содержащий настройки отображения папок классического почтового клиента panacea.dat
16.5.2.3 Псевдонимы файловой системы, относящиеся к модулям

Псевдонимы, относящиеся к модулям (plugins), предоставляются источником, который подключается к службе каталогов в тот момент, когда возникает необходимость в обращении к модулям. Эти псевдонимы используются для получения файла, реализующего модуль. Они доступны только в системе Microsoft Windows.

Прочие источники службы каталогов просто транслируют псевдоним в путь к соответствующим файлу или папке. Данный источник тоже возвращает файловый объект, но лишь после выполнения некоторых проверок. Так, он проверяет, достаточна ли версия модуля, установленного в системе, для отображения содержимого и активизирован ли модуль в настройках платформы. Файл модуля возвращается лишь при выполнении этих условий. Для сравнения версий используется формат, описанный в "Система распространения и установки - XPInstall" "Развертывание".

Известные псевдонимы представлены в таблице 16.19.

Таблица 16.19. Псевдонимы файловой системы, относящиеся к модулям
Псевдоним Описание соответствующего nsIFile
plugin.scan.SunJRE Файл модуля Java (Mozilla OJI)
plugin.scan.Acrobat Файл модуля Adobe Acrobat plugin file
plugin.scan.Quicktime Файл модуля Apple Quicktime plugin file
plugin.scan.WindowsMediaPlayer Исполняемый файл Windows Media Player
plugin.scan.4xPluginFolder Папка модулей Netscape 4.x
Наталья Алмаева
Наталья Алмаева
Россия
Дмитрий Казимиров
Дмитрий Казимиров
Россия, Омск