Библиотека сайта rus-linux.net
Фреймворк Telepathy
Глава 20 из книги "Архитектура приложений с открытым исходным кодом", том 1.
Оригинал: Telepathy
Автор: Danielle Madeley
Перевод: Н.Ромоданов
20.3. Соединения, каналы и клиентские приложения
20.3.1. Соединения
Соединение создается менеджером соединений с тем, чтобы подключиться к отдельному протоколу/аккаунту. Например, подключение к аккаунтам XMPP escher@tuxedo.cat и cami@egg.cat должно в результате привести к созданию двух соединений, каждое из которых представлено объектом на шине D-Bus. Соединения обычно настраиваются менеджером аккаунтов для аккаунтов, имеющихся в данный момент.
В соединениях предоставляются некоторые обязательные функциональные возможности, необходимые для того, чтобы управлять и следить за состоянием сетевых соединений, а также для того, чтобы выполнять запрос каналов. В них также может быть предоставлен, в зависимости от возможностей протокола, ряд дополнительных возможностей. Они предоставляются как дополнительные интерфейсы шины D-Bus (так, как это рассказывалось в предыдущем разделе), которые перечисляются в свойстве Interfaces соединения.
Обычно соединениями управляет менеджер аккаунтов, созданный с использованием свойств соответствующих аккаунтов. Менеджер аккаунтов также будет для каждого аккаунта синхронизировать присутствие пользователя в соответствующем соединении и может для указанного аккаунта запросить путь к соединению.
20.3.2. Каналы
Каналы являются механизмом, через который осуществляются коммуникации. Обычно каналом может быть обмен мгновенными сообщениями IM, голосовой или видео звонок или передача файла, но каналы также можно использовать для предоставления состояний самого сервера в случае, когда требуется сохранять состояние (например, поиск чат-комнат или контактов). Каждый канал представлен объектом шины D-Bus.
Каналы обычно образуются между двумя или большим количеством пользователей, одним из которых являетесь вы сами. Обычно у канала есть целевой идентификатор, который является либо еще одним контактом в случае соединения типа «один-один», либо идентификатором чат-комнаты в случае соединения сразу со многими пользователями (например, с чат-комнатой). В многопользовательских каналах предоставляется интерфейс Group, который позволяет вам отслеживать, какие контакты в данный момент подключены к каналу.
Каналы принадлежат соединению, и их запрос происходит из менеджера соединений обычно через диспетчер каналов; либо они создаются самим соединением в ответ на событие сети (например, входящий чат), а затем передаются диспетчеру каналов для диспетчеризации.
Тип канала определяется свойством канала ChannelType. Основные возможности, методы, свойства и сигналы, которые необходимы для данного типа каналов (например, для отправки и приема текстовых сообщений), определены в соответствующем интерфейсе Channel.Type шины D-Bus, например, в Channel.Type.Text. В некоторых типах каналов могут быть реализованы дополнительные возможности (например, шифрование), которые представлены в качестве дополнительных интерфейсов, перечисляемых в свойстве Interfaces. Например, текстовый канал, который подключается к пользователю многопользовательской чат-комнаты, может иметь интерфейсы, перечисленные в таблице 20.1.
Таблица 20.1: Пример канала текстовых сообщений
| Свойство | Назначение |
odfT.Channel | Общие возможности для всех каналов |
odfT.Channel.Type.Text | Тип канала, включающий в себя возможности, общие для всех каналов обмена текстовыми сообщениями |
odfT.Channel.Interface.Messages | Средства обмена сообщениями, имеющими расширенные возможности форматирования |
odfT.Channel.Interface.Group | Компоненты перечисления (list), отслеживания (track), приглашения (invite) и одобрения (approve) для этого канала |
odfT.Channel.Interface.Room | Чтение и назначение таких свойств, как тема чат-комнаты |
Каналы списков контактов: ошибка
В первых версиях спецификации Telepathy списки контактов рассматривались как тип канала. Было несколько списков контактов, определяемых сервером (пользователи-подписчики, пользователи, публикующие сообщения, заблокированные пользователи), которые можно было запросить у каждого соединения. Затем точно также, как и в случае с многопользовательским чатом, можно было содержимое списка получить с помощью интерфейса Group.
Первоначально это позволяло создавать канал только после того, как список контактов был полностью получен, на что в некоторых протоколах затрачивается много времени. Клиент мог запрашивать канал когда угодно, и получать его, как только он был готов, но для пользователей с большим количеством контактов это означало, что запрос мог вызвать таймаут.
Группы контактов (например, Friends - Друзья) также предоставлялись в виде каналов, по одному каналу на каждую группу. Это при разработке клиентских приложений, которые работали с ними, приводило к исключительно трудным ситуациям. Для таких операций, как получение списка групп, к которым принадлежал контакт, требовалось в клиентском приложении писать код значительного размера. Более того, поскольку информация была доступна только через каналы, такие свойства, как группы контактов или состояние подписки, нельзя было публиковать через интерфейс Contacts.
Теперь оба этих вида каналов были заменены интерфейсами, предоставляемыми самим соединением, которые предоставляют информацию о реестре контактов в виде, более удобном для авторов клиентских приложений, и которое, включает в себя информацию о состоянии подписки контакта (тип enum), списке групп, в которые входит контакт, и списке контактов в группе. Когда список контактов будет подготовлен, об этом будет сообщено с помощью сигнала.
Продолжение статьи: Запрос каналов, свойств каналов и диспетчеризация.