Рейтинг@Mail.ru

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

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




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

Twisted

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

Оригинал: Twisted
Автор: Jessica McKellar
Перевод: А. Панин

21.3. Взгляд в прошлое и выученные уроки

Проект Twisted недавно отметил свой десятый день рождения. С начала его создания под впечатлением от процесса разработки сетевой игры в начале 2000 годов, он в значительной степени достиг цели, заключающейся создании расширяемого, кроссплатформенного управляемого событиями сетевого фреймворка. Twisted используется в промышленных окружениях компаний от Google и Lucasfilm до Justin.TV и платформы для совместной разработки программного обеспечения Launchpad. Реализации серверов Twisted являются основой множества других приложений с открытым исходным кодом, среди которых BuildBot, BitTorrent и Tahoe-LAFS.

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

Также было одно важное удаление системы, которое практически не оставило следа в современной реализации: речь идет о системе постоянного хранения данных приложения Twisted.

Система постоянного хранения данных приложения Twisted
Система постоянного хранения данных приложения Twisted (Twisted Application Persistence (TAP)) предназначалась для сохранения данных конфигурации и состояния приложения в файле, формирование которого происходило с использованием модуля pickles из состава Python. Процесс запуска приложения при использовании этой системы состоял из двух стадий:
  1. Создание представляющего приложение файла с помощью на данный момент не используемой утилиты mktap.
  2. Распаковка данных приложения с помощью утилиты twistd.

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

Использование этих TAP-файлов сразу же привело к излишним сложностям. Классы фреймворка Twisted могли меняться без изменения экземпляров этих классов, упакованных в файлы. Попытки использования методов или атрибутов классов из новой версии Twisted совместно с упакованными в файл объектами приводили к краху приложений. Было введено понятие "систем обновления", которые должны были обновлять содержимое файлов при изменении версии API, но после этого возникла необходимость поддержки в актуальном состоянии матрицы из систем обновления, версий TAC-файлов и модульных тестов для учета всех возможностей обновления, хотя всесторонний учет всех изменений интерфейса был так же сложен и приводил к ошибкам.

Файлы TAP и соответствующие утилиты были лишены поддержки и в конечном итоге удалены из комплекта поставки Twisted и заменены на TAC-файлы и плагины. Аббревиатура TAC стала расшифровываться как Twisted Application Plugin (плагин приложения Twisted) и на сегодняшний день о неудавшейся системе хранения данных в Twisted напоминает только несколько фрагментов кода.

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

web2: урок о повторной разработке

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

В середине 2000 годов разработчики Twisted решили полностью переработать API twisted.web в рамках отдельного проекта на основе кодовой базы Twisted с названием web2. Проект web2 должен был содержать множество улучшений по сравнению с twisted.web, среди которых полная поддержка протокола HTTP 1.1 и API для работы с потоковыми данными.

Проект web2 считался экспериментальным, но в итоге начал использоваться основными проектами и даже был выпущен и упакован для дистрибутива Debian. Параллельная разработка web и web2 продолжалась в течение нескольких лет и новые пользователи не понимали того, какой проект стоит использовать из-за существования двух аналогичных проектов и отсутствия понятных рекомендаций на этот счет. Перехода на использование проекта web2 так никогда и не произошло, а в 2011 году проект web2 был окончательно удален из кодовой базы проекта и с вебсайта. Некоторые улучшения из проекта web2 медленно портируются в проект web.

Частично по причине событий вокруг проекта web2, проект Twisted заработал репутацию сложно структурируемого и не понятного для новичков проекта. Спустя годы сообщество разработчиков Twisted все еще занимается разрушением этого стереотипа.

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

В том случае, если в рамках проекта Twisted будет предпринят возврат к прошлому и снова начата разработка web2, разработчикам придется внести множество обратно совместимых изменений и объявить ряд функций устаревшими в рамках twisted.web вместо полной повторной разработки проекта.

Соответствие тенденциям развития Интернет

Методы использования нами сети Интернет продолжают развиваться. Решение о реализации множества протоколов в рамках основной кодовой базы Twisted привело к необходимости поддержки кода для этих протоколов. Реализации приходилось развивать в соответствии с изменениями стандартов и введением новых протоколов, при этом придерживаясь строгой политики обратной совместимости.

Проект Twisted в первую очередь развивается силами добровольных разработчиков и ограничивающим разработку фактором является не энтузиазм сообщества, а свободное время разработчиков. Например, спецификация RFC 2616, описывающая протокол HTTP 1.1, была выпущена в 1999 году, а работа по добавлению поддержки протокола HTTP 1.1 в набор реализаций протоколов Twisted началась в 2005 и закончилась в 2009 году. Поддержка протокола IPv6, описанного в спецификации RFC 2460 от 1998 года, находится в стадии реализации, но все еще не добавлена в основную кодовую базу по данным на 2011 год.

Реализации также приходится развивать в ходе изменения интерфейсов поддерживаемых операционных систем. Например, возможность получения уведомлений о событиях с использованием вызова epoll была добавлена в Linux 2.5.44 в 2002 году и, для того, чтобы использовать преимущества нового API, в Twisted был добавлен цикл обработки событий на основе epoll. В 2007 году компания Apple выпустила версию 10.5 своей операционной системы с именем Leopard, реализация вызова poll в которой не поддерживала работу с устройствами, причем этого изменения было достаточно для нарушения работы и блокировки компанией Apple интерфейса select.poll в своей сборке интерпретатора Python. Проекту Twisted пришлось предложить обходное решение этой проблемы и включить его описание в документацию для пользователей.

Иногда темп разработки Twisted оказывается недостаточным для реализации изменений сетевых протоколов и улучшения перемещаются в библиотеки, не относящиеся к основному коду проекта. Например, проект Wokkel, являющийся коллекцией улучшений поддержки протокола Jabber/XMPP фреймворком Twisted, развивался как предназначенный для слияния с проектом Twisted обособленный проект в течение многих лет без перспектив этого слияния. Ввиду того, что в браузеры начали добавлять поддержку нового протокола WebSockets, в 2009 году была предпринята попытка добавления поддержки этого протокола в Twisted, но разработка все же была перенесена в рамки отдельных проектов после решения разработчиков не включать в Twisted код поддержки протокола до того момента, как на основе черновика IETF не будет сформирован стандарт.

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

Twisted может быть и вашим фреймворком для работы с Интернет в течение следующих десяти лет.


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

Поделиться: