Лучше не надо :)

Вы не можете держать Х вебсокет коннектов одновременно и по чиху им всем разослать что-нибудь.

вот-вот, fcgi не удобный

вместо вебсокетов можно HTTP Long Polling

Для этого нужен mojo'вский render_later

не обязательно. даже каталист умел

Это в какой реинкарнации?

Для того чтобы так уметь надо уметь в эвент луп. А я что-то не помню чтобы Каталист умел в него

не вчитывался, но вроде вот оно https://stackoverflow.com/questions/20741087/catalyst-comet-long-polling

> It was a natural choice to implement my Comet app as a PSGI application.
Каталист вышел с чата.

А AnyEvent - зашел. Дальше понятно... На голом Plack'е это можно сделать, да.

Добрался я наконец до FCGI, но вот только ночью(

Вот спека, которую я нашёл в сети:
https://www.mit.edu/~yandros/doc/specs/fcgi-spec.html

Я писал выше про мультиплексирование, находясь в полном бреду :-)
Но внезапно FCGI его поддерживает. Более того, туда и event loop можно затащить.

> This supports applications that are able to process concurrent requests using event-driven or multi-threaded programming techniques.

Ещё выяснилось, что там могут быть 3 роли, которыми может быть FCGI приложение:
- Responder
- Authorizer
- Filter

Responder - это обычная обработка запросов.
Authorizer - для auth, если вернули 200, то auth прошёл (раздел 6.3)
Filter - не совсем понял, но чо-то типа FCGI приложение получает http запрос + file с web server-а и отдаёт фильтрованную версию данных (6.4)

В запрсах есть requestId, причём если поле занимает несколько байт, то у них там добавляется в структуре специальный суффикс B<n>, который говорит о том, какой это байт при склейки байтов.

Есть управляющие запросы, в которых web server спрашивает приложение о разных параметрах работы:
- сколько коннекции конкрентных к нему можно держать (FCGI_MAX_CONNS)
- сколько запросов могут быть конкурентных (FCGI_MAX_REQS)
- есть ли мультиплексирование (FCGI_MPXS_CONNS)

Удивило, что написано, какие дескрипторы должны быть у приложения закрыты (stdout, stderr) и что вместо stdout должен быть сокет web server-а.
Казалось бы какая разница?) Видимо отголоски CGI.

Короче, FCGI норм.

Наверное и web socket-ы можно на нём сделать, так как приложение посылает команду о том, когда считать запрос завершившимся (раздел 3.3 Managing Request IDs), посылает FCGI_END_REQUEST.

А что такое "на низких скоростях" в том комментарии?

нет, websocket не получится, выше уже написал почему - не сможете послать 101 Switching Protocols через fcgi-интерфейс

Я в посте по ссылке уже написал, как можно

ну кмк делать прокси и  транслировать websocket-cообщения в fcgi-запросы - это уже дичь, хотя конечно можно пойти дальше и транслировать в какой-нибудь smtp )

Вот и говорю: нет ничего невозможного :)

Это значит «с приемлемой лейтенси и rtt в условиях низкого rps»