Рейтинг@Mail.ru

Наши друзья и партнеры

UnixForum





Библиотека сайта rus-linux.net

Фреймворк Telepathy

Глава 20 из книги "Архитектура приложений с открытым исходным кодом", том 1.

Оригинал: Telepathy
Автор: Danielle Madeley
Перевод: Н.Ромоданов

20.3.3. Запрос каналов, свойств каналов и диспетчеризация

Запрос каналов осуществляется с указанием карты свойств, которые, как вы желаете, должны предоставляться каналом. Обычно при запросе канала указывается тип канала, тип целевого хэндла (контакт или чат-комната) и сама цель. Однако, при запросе канала могут также указываться такие свойства, как имя или размер файла в случае передачи файлов, будет ли при вызовах сразу включаться аудио и видео, какие каналы из существующих следует объединить в вызов типа «конференция» или на каком сервере контактов осуществлять поиск контакта.

Свойства в запрашиваемом канале являются свойствами, определяемыми в спецификациях фреймворка Telepathy, например, свойство ChannelType (смотрите таблицу 20.2). Указывается полностью квалифицированное пространство имен интерфейса, откуда берутся свойства, которые можно указывать в запросах каналов и которые, согласно спецификациям фреймворка Telepathy, помечены как requestable (запрашиваемые).

Таблица 20.2: Примеры запросов каналов

СвойствоЗначение
ofdT.Channel.ChannelTypeofdT.Channel.Type.Text
ofdT.Channel.TargetHandleTypeHandle_Type_Contact (1)
ofdT.Channel.TargetIDescher@tuxedo.cat

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

Таблица 20.3: Запрос канала передачи файлов

СвойствоЗначение
ofdT.Channel.ChannelTypeofdT.Channel.Type.FileTransfer
ofdT.Channel.TargetHandleTypeHandle_Type_Contact (1)
ofdT.Channel.TargetIDescher@tuxedo.cat
ofdT.Channel.Type.FileTransfer.Filenamemeow.jpg
ofdT.Channel.Type.FileTransfer.ContentTypeimage/jpeg

Каналы могут быть в двух состояниях created (созданы) или ensured (гарантируется, что они будут созданы). Гарантирование создания канала означает, что он будет создан только том в случае, если он еще не существует. Запрос на создание канала приведет либо к тому, что будет создан абсолютно новый канал, либо запрос завершится ошибкой в случае, если несколько копий такого канала не могут существовать одновременно. Обычно вам потребуется лишь гарантировать, чтобы были созданы каналы передачи текстовых сообщений и каналы звонков (т.е. вам достаточно, чтобы для разговоров с одним человеком был открыт только один канал, и, более того, во многих протоколах не поддерживает одновременно несколько разговоров с одним и тем же самым контактом), а создавать каналы нужно будет только передачи файлов и в случае каналов, в котором сохраняется их собственное состояние (stateful channels).

Оповещение о только что созданных каналах (по запросу или как-нибудь иначе) осуществляется с помощью сигнала, поступаемого из соединения. В этом сигнале содержится карта неизменяемых свойств канала (immutable properties). Это такие свойства, для которых гарантированно, что они не будут изменяться в течение времени существования канала. К свойствам, которые рассматриваются как неизменяемые и которые согласно спецификации Telepathy помечаются как immutable, обычно относятся следующие: тип канала, тип целевого хэндла, цель канала, инициатор создания канала и список реализуемых интерфейсов. Ясно, что свойства, описывающие текущее состояние канала не являются неизменяемыми.

Запрос каналов — старый подход

Изначально, каналы можно было запрашивать по их типу, типу хэндла и цели. Этот подход был недостаточно гибким, т. к. не для всех каналов указывается цель их создания (например, каналы поиска контактов), а для некоторых запросов каналов требуется в первоначальный запрос включать дополнительную информацию (например, при передаче файлов, получении голосовой почты и отправке СМС).

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

Возврат неизменяемых свойств канала, когда вы его создаете или обеспечиваете, чтобы он был создан, позволяет гораздо быстрее создавать прокси-объект для канала. Теперь эту информацию запрашивать не нужно. В ассоциативном массиве в таблице 20.4 показаны неизменяемые свойства, которые можно было бы добавить, когда делает запрос канала текстовых сообщений (например, в запросе канала, показанном в таблице 20.3). С целью упрощения некоторые свойства (включая TargetHandle и InitiatorHandle не показываются.

Таблица 20.4: Пример неизменяемых свойств, возвращаемых новым каналом

СвойствоЗначение
ofdT.Channel.ChannelTypeChannel.Type.Text
ofdT.Channel.Interfaces{[} Channel.Interface.Messages, Channel.Interface.Destroyable, Channel.Interface.ChatState {]}
ofdT.Channel.TargetHandleTypeHandle_Type_Contact (1)
ofdT.Channel.TargetIDescher@tuxedo.cat
ofdT.Channel.InitiatorIDdanielle.madeley@collabora.co.uk
ofdT.Channel.RequestedTrue
ofdT.Channel.Interface.Messages.SupportedContentTypes{[} text/html, text/plain {]}

Запрашивающая программа обычна отправляет запрос на канал диспетчеру каналов, передавая аккаунт, для которого производится запрос, запрос на канал и, возможно, имя требуемой программы-обработчика (это целесообразно, когда желательно, чтобы программа сама обрабатывала канал). Передача имени аккаунта вместо передачи соединения, означает, что диспетчер каналов может, если это потребуется, попросить менеджер аккаунтов перевести статус аккаунта в онлайн.

Когда запрос канала будет выполнен, диспетчер каналов либо передаст канал в указанный обработчик (handler), либо найдет подходящий обработчик (смотрите ниже обсуждение, относящееся к обработчикам и другим клиентским программам). Когда имя нужного обработчика является необязательным параметром, то у программы появляется возможность не интересоваться тем, ем, что в коммуникационных каналах при запросах каналов происходит за границами первоначального запроса, и отдавать все это на откуп тому обработчику, который для этого подходит наилучшим образом (например, запуская чат текстовых сообщений из вашего почтового клиента).

Рис.20.4: Запрос канала и диспетчеризация

Запрашивающая программа передает запрос канала в диспетчер каналов, который, в свою очередь, перенаправляет этот запрос в соответствующее соединение. Соединение выдает сигнал нового канала NewChannels, получаемый диспетчером каналов, который затем ищет подходящую клиентскую программу для обработки канала. Диспетчеризация входящих каналы, запросы на которые не делались, осуществляется аналогичным образом, когда сигнал, поступающий от соединения, получает диспетчер каналов, но, конечно, без первоначального запроса из программы.


Продолжение статьи: Клиентские программы.

Поделиться: