Рейтинг@Mail.ru
[Войти] [Зарегистрироваться]

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

UnixForum
купить дешевый 
компьютер родом из Dhgate.com




Lines Club

Ищем достойных соперников.

Библиотека сайта или "Мой Linux Documentation Project"

Фреймворк Telepathy

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

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

20.8. Усвоенные уроки

Фреймворк Telepathy является превосходным примером того, как можно поверх D-Bus создать модульный и гибкий интерфейс API. Он показывает, как нужно поверх D-Bus разрабатывать расширяемый фреймворк, состоящий из нескольких слабо связанных между собой частей. Причем такой, для которого не нужен центральный управляющий демон, и в котором отдельные компоненты можно запускать независимо друг от друга и без потери данных в других компонентах. Telepathy также показывает, как можно эффективно использовать шину D-Bus, минимизируя объем трафика, передаваемого через шину.

Рарзаботка Telepathy была итеративной, постепенно улучшавшей использование шины D-Bus. Были ошибки и были усвоены уроки. Далее перечисляется наиболее важное из того, что мы усвоили, когда разрабатывали архитектуру Telepathy:

  • Использование свойств шины D-Bus; чтобы получить информацию, не нужно вызывать десятки методов D-Bus. Для каждого вызова метода для передачи данных туда и обратно требуется некоторое время. Вместо того, чтобы делать массу отдельных вызовов (например, GetHandle, GetChannelType, GetInterfaces), используйте свойства шины D-Bus и получайте всю информацию с помощью одного вызова GetAll.
  • Когда объявляете о создании нового объекта, то предоставляйте столько информации, сколько вы можете предоставить. Первое, что обычно делают клиенты, когда узнают о новом объекте, это делают запрос всех свойств объекта, чтобы решить, нужен ли им вообще данный объект. Если включить все неизменяемые свойства объекта в сигнал, оповещающий о создании объекта, то большинство клиентов сможет определить, насколько им интересен данный объект, не делая при этом никаких вызовов методов. Более того, если им интересен объект, им не нужно беспокоить его запросами о неизменяемых свойствах.
  • Интерфейс Contacts позволяет запрашивать информацию сразу из нескольких интерфейсов. Вместо того, чтобы получать всю информацию о контакте с помощью большое количество вызовов GetAll, вы можете с помощью интерфейса Contacts запросить всю информацию за один раз и, при этом, сэкономить большой объем трафика, передаваемого через шину D-Bus.
  • Не используйте абстракции, которые не совсем подходят. Предоставление реестра контактов и групп контактов в виде каналов, реализующих интерфейс Group, казалось неплохой идеей, т.к. для этого использовались существующие абстракции, а не добавлялись новые интерфейсы. Однако, это сделало реализацию клиентских приложений сложной, что, в конце концов, перестало нам подходить.
  • Убедитесь, что ваш интерфейс API будет в будущем соответствовать вашим потребностям. Первоначальный интерфейс API запроса каналов оказался недостаточно гибким и позволял делать лишь весьма общие запросы. Это нам не подошло, когда нам понадобилось делать запросы в каналы для получения большего количества информации. Этот интерфейс API пришлось заменить другим, который был намного более гибким.

Примечания

  1. http://telepathy.freedesktop.org/ или смотрите руководство разработчика на http://telepathy.freedesktop.org/doc/book/
  2. http://telepathy.freedesktop.org/spec/
  3. Далее мы будем сокращать /org/freedesktop/Telepathy/ и org.freedesktop.Telepathy как \code{ofdT} с целью экономии места.
  4. Например, XMPP (Extensible Messaging and Presence Protocol, т.е. расширяемый протокол обмена сообщениями и информацией о присутствии.)


К началу статьи.


Эта статья еще не оценивалась
Вы сможете оценить статью и оставить комментарий, если войдете или зарегистрируетесь.
Только зарегистрированные пользователи могут оценивать и комментировать статьи.

Комментарии отсутствуют