Некоторые раздумья о Zope3, Zope 3 приложениях и Zope 3 экземплярах

Я рад поделиться некоторыми размышления о том, что такое Zope 3 (для меня), что такое Zope 3 приложение и что такое Zope 3 экземпляр есть или должен быть.

Я думаю, это должно повлиять на наши раздумья о Zope3 релизах и интрсументах, которые мы создаем, такие как zc.buildout и скрипты для него, которые помогают строить и развертывать приложения.

Во-1-ых немного основ:

Zope 2 был первым и наиглавнейшим приложением. Он был расширяем и пользователи могли строить приложения поверх него, но это делалалось через механизм расширений. Со временем, все больший и больший акцент делался на постороении приложений поверх него. Я думаю, что это было и остается чрезвычайно полезным приложением. Я счастлив видеть сходные приложения, построенные с использованием Zope3. Возможно, таким приложением когда-нибудь станет Zope2.

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

Современный дистрибутив Zope3 также содержит приложение, которое во многом сходно с Zope2. Оно содержит дерево объектов и ZMI (интерфейс управления Zope). По крайней мере сейчас, когда устанавливается Zope 3, устанавливается приложение, которое сразу же может быть запущено, что бы делать что-то ценное. В этом документе, будем называть это приложение системой выполнения объектов (OFS, Object Filling System).

Я убежден, что OFS полезен, когда разрабатывается сам Zope3. OFS на самом деле была действительно первым приложением, разработанным с Zope 3. Также существует несколько видов приложений, которые используют OFS как стартовую точку. Мы построили системы управления контентом, которые используют большую часть OFS. В последнем случае, мы используем ее скорее как библиотеку, а не как приложение. Не очевидно, что OFS имеет большое значение как приложение, в ее современной форме.

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

• Развертывание должно быть высокоавтоматизировано (мы двигаемся к использованию таких приложений, как RPM в среде нашего хостинга. Эти RPM'ы создаются с использованием zc.buildout и включают приложения и инструменты для создания экземпляров приложения.)
• Развертывание, как такое, как мы однажды делали, имеет много (десятки) экземпляров одного и того же приложения.
• Приложения должны быть хорошо управляемы. Среди прочих вещей, это означает, что составные части приложения, такие как программное обеспеячение, конфигурационные файлы, логи и так далее должно размещаться в предсказуемых, легко доступных местах (см. напр. http://www.pathname.com/fhs/).

Скрипт mkzopeinstance не решает эти проблемы достаточно хорошо. Его трудно автоматизировать и оно не так гибко, как нужно, что бы определить множество прикладных параметров. Когда множетсвенные экземпляры используются, это приводит к множетсвенным повторениям. Крайний случай этого - директория package-includes (или Zope 2 директория Products). Каталоги экземпляров приложений размещаются таким образом, который вызывает серьезные нарекания у Unix-администраторов. Имея дело с многими экземплярами, я обнаружил, что традиционная раскладка экземпляра приложения по директориям трудна для использования на рабочих серверах.

Одной из проблем с традиционными Zope-экземпляры - это то, что они комбинируют тексты приложений и конфигурацией. Например, Zope 3 экземпляр, созданный mkzopeinstance включает множество ZCML-файлов, включая такие файлы как site.zcml и содержимое package-includes. Он также содержит множество генерированных скриптов. Эта информация практически идентична от одного экземпляра приложения к другому.

Мои текущие раздумья, FWIW:

Теперь для меня не очевидно, что приложение Zope3, которое мы сейчас распространяем, имеет большое значение. Было бы интересно услышать мысли других людей об этом. Я рад видеть некоторую популярные Zope 3 приложения или приложения, которые пользователи скачивают и используют, что бы почувствать преимущества Zope3. Я не знаю никого, кто разрабатывал бы что либо, похожее на это. Я надеюсь, что они есть. Я не думаю, что кто-то пытается переключить сществующее OFS в приложение, такое же как это.

Если Zope3 на самом деле преимущественно библиотека, то может быть мы должны распространять его таким путем, как eggs или setuptools совместимые дистрибутивы исходных текстов.

Zope Corporation создает приложения с Zope3. Пока этиа приложения используют много компонент из OFS, они не являются ни частью OFS, ни ее расширениями. Мы не используем package-includes. Более того, мы определяем пакет приложения, которое имеет ZCML-файлы, которые включают ZCML-файлфы для пакетов, которые мы используем. В будущем,наши пакеты приложений будут иметь завивсимости в стиле setuptools на пакеты, которые они используют. Традиционый Zope3 дистрибутив может стать малополезным для нас.

Я буду рад отделить определения приложения от определения экземпляра приложений. Для наших нужд, это будут "рецепты" zc.buildout для определения Zope 3 приложений. Эти приложения будут состоять из генерированного site.zcml файла, незначительного количества скриптов и пачки пакетов eggs. В отличие от скриптов, генерируемых mkzopeinstance, скрипты, генерируемы новым способом будут независимы от экземлпляров и не будут содержать встроенных путей к конфигурационным файлам.

Кроме того, будут рецепты экземпляров, которые смогут генерировать экземпляры приложений. В среде Unix, эти приложения будут размещать файлы более-менее в соответствии с http://www.pathname.com/fhs/. Больше не будет директории жкземпляра приложения, хотя для разработоки, они остануться, но будут много меньше, чем те, которые произхводяться существующим mkzopeinstance. Они, вероятно, будут включать в себя zope.conf файлы и контрольные скрипты, и их директории будут также содержать log-файлы и сокеты Z-демона. Экземпляры не будут содержать ZCML файлы, потому что ZCML файлы есть часть определения приложения, а многочилсенные экземпляры приложения будут разделять определения приложений.

Заключение:

Я вижу Zope 3 приложения как отдельные от OFS сущности. OFS-приложение не будет чем-то, что мы используем непосредственно. Экземпляры будут экземплярами наших приложений, а не Zope 3.

Я должен заметить, что существует множество удачных Zope 3 приложений, которые не являются OFS. Фактически, некоторые ранние Zope3 приложения не были даже основаны на OFS.

Ничто из выше сказанного не должно восприниматься как приказ какого-либо сорта. Пока что я всего лишь хочу породить обсуждение. Я не собирался начинать с каких либо аргументов.

Jim

От редакции:

Это просто замечательно, что Zope-разработчики, наконец, на своем опыте прочувствовали все то, о чем долгое время говорили эксплуатационники и различные дистрибутивостроители - от AltLinux до Debian. Невозможность уложить Zope в FHS была очень большой проблемой. Я рассматриваю это письмо как некий поворотный столб, просто потому, что несколько лет назад было написано аналогичное письмо, написано оно было автором сегодняшнего mkzopeinstance и всего, что с ним связано, и было направлено против FHS, причем в весьма агрессивной манере: "... идиотская привычка юниксных приложений размазыватся по всему диску ...", - это как бы одна из самых мягких цитат.

Хотелось бы, правда, вместо каких-то отвлеченных умствований про zc.buildout увидеть какое-то осознание того, что в юниксах существует вагон и маленькая тележка менеджеров пакетов, и накоплен __огромный__ опыт по решению таких проблем. В общем, у меня осталось некоторое ощущение не профессионализма ... с точки зрения теории и практики юникса, разумеется.

Ну что же, будем надеятся что на этот раз силы разума возьмут верх над силами добра :). А мы будем с интересом следить за развитием событий, да и вам рекомендуем. Итак, обсуждение началось здесь: mail.zope.org