1) Ядро движка.

Собственно, ядро состоит из двух (пока) библиотек - API и ADI.
С первой всё ясно уже из названия - это главная функциональная
библиотека, всё основные функции хранятся там. Вторая либа
предоставляет админ-API-функции (ADministrative Interface) -
используется главным образом для построения
админ-интерфейсов к модулям и взаимодействию с главным
admin-модулем движка. На самом деле ADI базируется на API, и
эту библиотеку нельзя считать самостоятельной - скорее, это
как надстройка над API.

2) Модульная расширяемость возможностей.

Вообщем-то, стандарт дефакто в современных CMS, и удивляться
тут нечему. В нашем случае, модули вызываются ядром движка
(ну, не совсем так, но сойдёт ). При этом модули могут
использовать все функции API не вызывая конструктор движка.
Т.е. мы как-бы импортируем функции модуля в ядро движка и
пользуемся ими, как внутренними. Также возможно использование
функций других (ранее загруженных) модулей. В целях экономии
памяти, модули грузятся избирательно - только те, которые
необходимы на данной странице (Хотя можно грузить и все
каждый раз, достаточно указать initMods => 1 в описании вызова
конструктора API). Также возможно использование модулей
расширения возможностей самого движка - в этом случае
можно как добавлять новые функции в ядро, так и перезаписывать
старые функции новыми.

3) Возможность ПОЛНОЙ смены дизайна (вот она, вкусность).

Возможности языка perl позволяют использовать
шаблонизированный вывод, благодаря regexp-выражениям
(изюминка perl), чем я и воспользовался. XEN позволяет
настроить себя под любой дизайн (мы ведь не говорим о
таком отстое, как фреймы, правда ? ;)). При этом вэбмастеру
не нужно разгребать бешенные кучи из смеси кода и HTML,
как это есть в PHPNuke. Зачем вэбмастеру быть
web-программистом, если он вэбмастер, и это не входит
в его компетенцию ? Вот и я о том же....

4) Использование СУБД.

Конечно, это тоже не является новинкой - сейчас все современные
и уважающие себя CMS используют различные СУБД для
хранения данных. Вот и я решил, что все данные должны
храниться в БД - ведь это в с одной стороны удобно для
разработчика, а с другой стороны это удобно и для владельца
сайта, ведь этим обеспечиватся огромная гибкость -
дистрибутив CMS можно переставить и не нужно
рыть и вытаскивать какие-то файлы с данными из
дистрибутива. Все данные можно на крайний случай
вытащить из БД в один файл. В XEN я использовал СУБД
MySQL (по слухам, mSQL тоже прокатит ;)).
Почему именно они ? Потому что MySQL быстрая, надежная
и некоммерческая СУБД, которая использутся большинством
хостеров. А ещё, потому что я другие незнаю... ;))

5) Безопасность.

Этому я уделяю особое внимание, так как дырявый движок
никому не нужен (особенно мне ). Особое внимание я уделяю
таким багам, как возможные SQL-Injection. Include баги совсем
не наблюдаются, да и я редко где встречал Include-баги в perl -
это прерогатива PHP . Хотя, криворукие кодеры на всё
способны . Доступ к коммандной строке нереален (невозможен
не могу сказать - всё возможно ), т.к. единственные операции
с файлами - это чтение шаблонов (причём права доступа явно
указаны, как и месторасположение шаблонов).


6) Скорость и размеры.

Я думаю, что ни для кого не будет секретом, что perl работает в
разы быстрее, чем PHP (Тихо-тихо ! Не кричите так громко !
Это уже доказано ) А если ещё и через mod_perl или FastCGI
- то вообще супер ! О размерах... Сейчас XEN (v0.5.6-dev)
в tar.bz2 архиве весит ~80 Кб. Ну как ?