Библиотека сайта 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- Создание представляющего приложение файла с помощью на данный момент не используемой утилиты
mktap
. - Распаковка данных приложения с помощью утилиты
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 может быть и вашим фреймворком для работы с Интернет в течение следующих десяти лет.