Socket.io ещё не стабилен на высоких нагрузках

Что значит не стабилен? О какой именно не стабильности вы говорите?

node-webkit проще в употреблении, нежели TideSDK, когда речь идёт о создании приложений с графическим интерфейсом на десктопах методами веборазработки

Я думал, что в этом они одинаковые так как используют одни и те же веб-технологии (html, css, js). Или я что-то не понимаю?

Только derby используют socket.io, что совсем меняет картину.

Можете подробней объяснить, что вы хотели сказать?

Сначала можно посмотреть лекции Крокфорда (хотя бы вторую).
Потом можно почитать Eloquent JavaScript (может как базовую книгу кто-то посоветует другую)
Потом пройти туториал Резига
Потом досмотреть все лекции Крокфорда.
А дальше можно пересмотреть все оставшиеся ссылки из статьи (wtfjs, js patterns...)

Так это потому, что Java взяла этот синтаксис из С. А С взял какие-то вещи из Fortran. Посмотрите лекцию Крокфорда, там все подробно рассказано

Вот если бы его можно было использовать для создания сценариев или компилировать в JS…

Выбирайте здесь или здесь (вот эта ссылка есть в посте)

А какой язык вы считаете «удачным»? Просто любопытно

В доме который построил Джек…

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

Если быть точным, то в честь сорта кофе, который производится на одноименном острове.

А Джава (если верить русской википедии) — это поселок в Осетии ))

Иностранцы, ее произносят как Джава. Но я думаю, что это дело вкуса. Поэтому исправил на JavaScript.

исправлено

Я о том же хотел сказать, что futures это круто, но как-то синтаксического сахара не хватает…

Я так понял, что это разновидность control flow (futures). Показаыне примеры кода меня как-то не впечатлили. Может я чтол-то не понимаю…

Да, неплохо. Категоризация местами хромает, но лучше чем ничего.

Я хотел список «мейнстримных» пакетов.

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

Следующая тонкость — в моем описании есть небольшая подмена понятий. Группа (которая отражает принадлежность к иерархической структуре в реальном мире) и группа (роль) в системе разделения прав не всегда одно и тоже. Специально оставил, так как сам наступал на эти грабли (думаю, не я один). Нужно разделить понятия группа и роль. Тогда можно будет сделать соотношение между ролями и пользователями многие ко многим.

Гостям вообще разрешить только смотреть

allow('guest', 'read', 'posts[not_only_for_moderators]')

Админам можно все
allow('admin', 'all', 'all')

Надо в некоторые разделы запретить постинг на первый месяц, некоторые сделать доступными только модераторам.

allow('members', 'read', 'posts[not_only_for_moderators,not_fitst_month]') allow('members', [read, 'post'], 'posts[not_only_for_moderators,fitst_month]')

Еще хочется на отдельные темы (!) назначать персональных модераторов.

allow('moderators', 'all', 'posts[where_moderator]') allow('moderators', ['read', 'post'], 'posts[only_for_moderators]')

Все просто если отделить бизнес логику от ACL. Назначение модератора в раздел это бизнес логика. Объясню на примере:
Пользователь является автором поста не потому, что он может редактировать пост, а потому что он написал этот пост и при создании поста система записала в базу текст поста и текущего пользователя как автора.
Эта информация может использоваться для разделения прав, а может и не использоваться. Может использоваться для получения списка всех постов данного пользователя.
Если на ситуацию смотреть под таким ракурсом, то любая задача решается. Была бы соответствующая бизнес логика, а навернуть сверху разделение прав всегда можно.

Вот если модератор — надо в лог записать, что модератор совершил действие.

Тут надо различать два действия: редактирование автором и редактирование модератором.
За ними стоит разная бизнес логика:
— при редактировании автором запись происходит только в таблицу с постами
— при редактировании модератором запись происходит в таблицу с постами и в таблицу с логами (в таблицу, если их потом надо просматривать конечному пользователю)

потому что универсальные, позволяют решить задачу в общем виде

Базовый интерфейс (а именно функция can) тоже может решить задачу в общем виде.

У меня нет опыта использования Yii (поправляйте, если что-то неправильно понял). Вот, что я понял из документации:
— нельзя назначить много ролей юзеру (вместо этого предлагают использовать наследование ролей)
— нет готового решения для задачи с атрибутами ресурсов

Мое решение «на бумаге». Если найдется желающий, то он может реализовать его под интерфейс Zend_Acl