Степан Ломов

2009.01.01

Попытка не пытка

Для тех кто спрашивает, чем похожи и чем отличаются zope2, zope3, plone я пишу этот мемуар :). Тут нет точных дат и вообще - это скорее мои ощущения от реальности, чем сама реальность. Поэтому за точными датами и данными отправляйтесь-ка в гугол, а я рассказываю как помню.

Словарь

Основная форма:Zopelada
Род:Мужской
Падежное оканчание-oe
Синонимы
Zope, Plone, Zope3, CMF

Событие

Где:Москва, Планерная
Когда:2008.07.04

Начало: Zope2

Я не слишком следил за поворотами судьбы этих трех продуктов, просто все время был одним из разработчкиков систем на их основе. Поэтому у меня есть некоторое _ощущение_ истории развития этих продуктов и отношений между ними. которое может совершенно расходится с реальными событиями, датами и людьми.

Я познакомился с Zope2 где-то в начале 2000го, когда это был революционный продукт, имеющий очень мало аналогов, особенно в мире открытого програмного обеспечения. Его основными отличиями (помимом того, что это был сервер приложений), было использование Объектно-Ориентированной базы данных (что было модно тогда и сейчас) и использование особой методики наследования среды выполнения запроса при травересе объектной иерархии, названной "Заимствавание", которое было изобретением одного из идеологов Zope и превращала программирование под ним в опасный, но очень интересный ребус.

Многие трудные на вид задачи легко решались c применением заимствования. Суть заимствования - объект полученный из другого объекта (безразлично, как из контейнера, через атрибут или функцию - знатоки питона знают что разница тут чисто номинальная), заимствовал среду, или пространство имен исходного объекта, и, хотя поведение чисто формально не менялось, в этой другой среде оно выглядело по другому. Это давало какую-то простоту: взять запрос, траверсом от него получить исполнителя запроса и просто вызвать его по call(), после чего получался ответ, который отдавался серверу. Это была магия - безумная, но удивительно красивая магия.

Сам же Zope2 был в то время просто некрасивым сервером приложений с двумя красивыми технологиями. Под него можно было написать сайт, просто напихав в базу исполняемых темплейтов на DTML, или же попытаться сделать что-то тиражируемое. Разные группы разработчиков писали под него свои CMS среды, следуя его ограничениям, главное из которых - дешевый, тиражирумый код получался только как единый крупный и жестко регламентированный проект.

Было два типа таких проектов: разработка новых коллекций объектов и разработка новых скинов. Скины тиражировались с большим трудом, в основном за счет репликации (напомню, что тогда весь код скина хранился в ZODB), Как правило, относитеьлного коммерческого успеха добивались те, кто ухитрялся некий инвариант тиражируемого скина вынести в иерархию своих объектов, и после этого передать программирование скинов программистам послабее. Но все равно нужен был талант.

Экспансия: Plone

Ситуация не могла оставаться долго в таком состоянии, потому что рынок требовал сайты, сайты, сайты и все эти сайты должны были отличаться только внешней оболочкой (скином) в которой должна была быть возможность использовать многие тиражируеме решиния (например календари, блоки прокрутки). И в какой-то момент нашлась группа, которая взяла на себя смелость стандартизовать и регламентировать скин. Сделав его _тиражируемым_ продуктом.

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

Очевидно в этот момент рынок веб технологий слегка изменился и потребностть в уникальной картинке отошла на второй план - против юзабилилити и спектра возможностей, а последние версии скина plone приближаются по своей функциональности к толстым клиентам. Кажется, это был примерно 2004ый год, который рядом авторов (например Нильсеном) называется годом такого же перелома рынка, хотя и безотносительно к Zope2 и Plone.

Я не особо сильно программировал на Plone: в этот момент я участвовал в борьбе уже как консультант, и на плон смотрел со стороны. Да и претило мне это, если честно: плон был есть и, видимо, будет, только "шкуркой" для Zope, эдаким прибежищем для php программистов, которым php поменяли на ZPT, и добавили некий регламент размещения скриптов, написали кук-бук и думми-гайд и вперед с кирками и лопатами на завоевание мирового господства. Мировое господство, надо сказать, получилось.

В то же время, PLonе все-таки был генератором идей, хотя и не воплощал их сам, и одной из таких идей стала смерть заимствования, по крайней мере в том виде и в том объеме как это было в Zope2. Относительно низкий общесистемный уровеноь среднего plone-разработчика исключал возможность понимания им этой техники, и хотя формально plone тоже был на ней основан (иначе он не работал бы) это знание от конечного разработчика скрывалось и им не использовалось.

В Отрыв : Zope3x

Отночительно этого момента у меня некоторый исторический пробел и размывание перспективы. Потому что, с одной стороны начинается резкий рывок в области развития ZODB до промышленного уровня (т.н. ZODB4). С другой стороны происходит резкий рывок языка Python, который позволяет уникальные технологии, использованные в ZODB / ZOPE и реализованные за счет си-расширений сделать частью ядра языка. В частности, в какой-то момент ZODB отказывается от части своего кода в пользу стандартной рализации на Python, C третьей стороны формируется концепция Zope3 и начинается его разработка. Я не следил тогда за Zope3, и не могу сказать кто внес в него компонентную модель, на то время мы сами писали CORBA сервер поверх ZODB и компоненты у нас были свои :).

Однако участники Zope/ZODB фронта говорили о текущем положении дел как о совершенно новом варианте сервера и базы данных, принципиально несовместимых с ранее существовавшим. Появился даже некий план развития (полностью провалившийся по срокам да и выполненый лишь частично), в котором точками отсчета были Zope3x и Zope3, причем Zope3 должен был содержать режим обратной совместимости для запуска Zope2 приложений. Которого, насколько я знаю, нет и сейчас.

Облом : The Five

И вот, на волне этого подъема и ухода разработчиков в отрыв, происходит резкий облом. Сворачивается разработка Zodb4. Насколько я понимаю - не хватилоо не денег, а просто профессионализма. Когда рабочая группа увидела RUP, базы типа CACHE и промышленные менеджеры распределенных транзакций, они поняли что на этот рынок им не войти.

Поняв, что денег и песочницы для Zope2 не будет, а наработки на фронте разработки полезные, часть кода zodb4 переносится в zodb3. Одновременно появляется "проект 5" - Five. Zope3 _в_ Zope2, который позволяет писать продукты Zope2, используя возможности, которые есть в Zope3. В какой-то момент со стороны казалось, что все, Бобик сдох.

Стагнация : Zope3

Но Zope 3x вышел (хоть и с опазданием) мы начали под него программировать и увидели что хоть свет и сероват, но хорош. Zope3 + Zodb выгребают в точку стабилизации и чистят свой код, причем, повидимому из-за резкого останова было сделано менее 20% проекта и этот огрызок теперь преподносится как целый проект.

На сегодняшний момент, по проработанности кода Zope3 испытывает период стагнации. И очень сильно отстает по критичным функциональным точкам от Zope2. Например, репликация, работающая на уровне ZODB, не сработает для части объектов современного Zope3. Этот объект можно назвать - IntIds (ну, программисты на zope3 поняли: репликации нет). Это решаемо, но не решено

Zope2 развивается в угоду Plone и не более, по крайней мере начиная с версии 2.7: 2.8 перешла на ZODB в новом формате, 2.9 включила в себя Five. Сам Zope2 практически не развивается, даже хотпатчи не выходят начиная с версии 2.6, Но в нее включают компоненты, API которых совпадает c API Zope3, на них переползает Plone и так происходит что-то вроде конвергенции между неподвижным Zope3, Zope2 с бакпортами и распластаном на нем, как улитка на кактусе, Plone.

Оптимистичное будущее : Zope3 + Plone

Видимо, в течении __года___ zope2 и zope3 с точки зрения plone станут идентичными. И будет заявлено что новые проекты на plone лучше создавать уже на Zope3. И тогда мы заговорим о Zope3 + Plone.

Я надеюсь что ситуация будет такой. Zope2 по уровню функционала постепенно доведут до частичной совместимости с Zope3. Plone переведут на это урезаное API. В дальнейшем, новые plone сайты станут запускать на Zope3 (он формально быстрее и качественнее), пытаясь поддерживать совместимость с Zope2. Но низкоквалифицированные Plone программисты быстро поломают все регламенты, и начнут использование полного API Zope3. После этого Zope2 за пару лет прекратит свое существование и plone официально начнет использовать полное API Zope3, избавляясь от костылей, унаследованных от Zope2.

И тогда начнется развитие уже Zope3, правда, во многом как составной части Plone. Zope3 в силу компонентности может перенести это легче. Наверно, в это время начнут развиваться толстые клиенты для управления контентом Zope3 (прототипом такого клиента, ng.xmlrpcscan, я пишу эту статью).

Пессемистичное будущее : Zope3 умер

Может случится и другое. Часть функционала бакпортят из Zope3 в Zope2. И Zope3 закрывают. Как это было с ZODB4.

Заключение

Все. Я рассказал все свое виденье. Только имейте ввиду - это было как пересказ сна. Реальные события были какими-то другими. Это такой, Zope-эпос. Zopeлада.

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

Отсюда следует два забавных вывода:

  • Не надо так делать, тем более что это работает!
  • Раз уж это работает, то хорошо бы придумать идею, как это применить.
  • Такой уж вот парадокс :)

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

    Отсюда следует два забавных вывода:

  • Не надо так делать, тем более что это работает!
  • Раз уж это работает, то хорошо бы придумать идею, как это применить.
  • Такой уж вот парадокс :)

    Эпицентр Zope3 тут Нейросети Нейросети-2 Репозиторий Слив! Статистика Редакторам Подписка