Comet

[Vitaly Puzrin]

VP>> Где я усложнил абстракцию? Я объяснял внутренности, которые делаются
VP>> уже на уровне php и js. От nginx требуется только держать репитер и перекидывать что дают.
AS> нет не только, проблем держать соединение у него нету, есть
AS> проблемы что в эти соединения потом писать
AS> после того как он отключился от backend, особенно учитывая что
AS> этих конектов будет много и в каждый может быть
AS> надо писать что-то свое. если же он не отключается от backend то
AS> возникает вопрос что в какие коннекты дублировать
AS> (комнаты, приваты в терминологии чатов) а для этого nginx уже
AS> должен много знать о логических процессах в конкретном
AS> приложении.

Либо я плохо объяснил, либо вы не так поняли.

nginх содержит только список ID подключенных потоков. Если данные
поступают - прокидывает их в скрипт, вместе с ID источника
(предлагалось ID добавлять в заголовок запроса). От скрипта в ответе
идет ответ, и список ID, в которые надо распараллелить ответ.

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

Если у вас какие-то специфические задачи - приведите пожалуйста
пример. Для тех чатовских фишек, которые вы перечислили, достаточно
примитивного абстрагированного мультиплексора. Мне не сложно накидать
архитектуру чата, но мы в сторону уйдем. Если вам серьезно надо для
работы - пишите на мой email, что смогу - расскажу, мне не жалко.

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