Попытка не пытка
Для тех кто спрашивает, чем похожи и чем отличаются 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лада.