Готов работающий прототип для Акме (0.x→1.0?), в котором:

1. хитро поддерживаются дружественные урлы;
2. действия могут запускаться в двух контекстах: первичный и вторичный;
3. методы всех уровней имеют единый API, который в минимальном виде ограничивается кодом ответа.

Как освобожусь, буду переносить на него текущую версию Акме (0.7+). А пока — чуть более подробное описание прототипа:

1. Урлы

1. проекция урла на код (поиск действия по первому компоненту урла); если не вышло, то:
2. проекция урла на данные (поиск элемента дерева¹ с наиболее похожим на урл супертегом)

2. Действия

1. Действие запускается как первичное; может выбирать content-type. Если это application/xhtml+xml, то:
2. Запускается шаблонизатор, который может запускать другие действия как вторичные (они уже обязаны предоставлять контент только в application/xhtml+xml; если что, могут давать линк на себя, тогда по линку они запустятся в первичном контексте)
3. Все действия в любом контексте могут переформулировать внутренний урл (см. API) и перенаправить его в другое действие. Контроль числа «прыжков» (защита от бесконечного цикла).

3. API

3.1. Вызов

Как обычно, $h->interact({ foo => 'bar' });, т.е. именованные аргументы. При этом для действий (в т.ч. вложенных) аргумент path содержит ссылку на массив следующего вида: [ 'user', '1', 'profile', 'edit' ]. Каждый модуль (звено цепочки вызовов) откусывает необходимое ему число аргументов и работает с ними; далее он может вызвать свой подмодуль, передав ему измененный путь, или переформулировать начало пути и вызвать другое действие.

Т.о., path — из браузера, шаблона или кода — является главным средством оформления запроса к действию. Ессно, это не распространяется на другие модули (не действия).

3.2. Ответ

Примерный вариант ответа:

$response = {
	code    => 200,
	content => {
		name => "Greeting",
		type => "application/xhtml+xml",
		body => "<p>Hello world!</p>"
		}
	};

Обязательным элементом является только code (код ответа). Коды ответа взяты из спеков HTTP. Итак, в API минимальный ответ выглядит так: { code => 404 }. Этот код будет передаваться по цепочке назад, пока не будет заменен или не достигнет контроллера. В контроллере код ответа будет преобразован в нормальный текст через gettext (i18n), т.е. будут заполнены $response->{content}{name} и ...{body} (если переменные были пусты). Затем все это отдается шаблонизатору.

Внутри content нет обязательных элементов; могут быть дополнительные.

Примечания:

¹ Дерево состоит из категорий. Это жесткая иерархия на вложенных множествах. К категориям цепляются сообщения. Но на самом деле категория может быть и сообщением тоже. Это две роли узла. Таким образом, мы можем спокойно сажать в урл (и меню) как категории, так и сообщения.
Комментарии не могут быть узлами.

Кстати, прототип весит 17 кб вместе с документацией и дебаговым мусором. Вот поэтому меня особенно бесят всякие JS по полмегабайта.