> CGI не годится для долгоживущих
> соединений чуть более, чем совсем.Что годится для соединений долгоживущих?
> CGI — одна из «святых коров» закостенелых админов (не старых,
> не опытных, а именно закостенелых, это не от возраста зависит), не
> желающих даже смотреть на что-либо новое, ведь позволяет писать серверную часть
> абы как и долго не замечать (читай, игнорировать) проблемы разной степени
> серьёзности (вплоть до чего-нибудь типа повреждения кучи).
> А если под «cgi-скриптом» подразумевалось
> вообще любое серверное ПО для генерации
> динамики (а не конкретно используемые через CGI программы)
Чем на сервере генерируют динамику незакостенелые админы?
>> Ну "для сэбэ трошки" POP3 при грамотной настройке работает
>> нормально. И проблем не возникает, если грамотно настроить
>> маршрутизацию почты так, чтоб она была доступна везде в
>> нужных местах. Но это, повторю, верно "для сэбэ трошки"
>> - для людей, умеющих работать грамотно - програмимстов,
>> сисадминов и т.п. А для смертных в промышленных масштабах
>> про POP3 сказать ничего не могу - не работал с почтой
>> масштабно аки крупный почтовый провайдер.
> ради, вероятно, поддержки чувства собственной важности.
Возможно, что где-то такие конфигурации используются по причине поддержки этого чувства.
Но мой случай более прост:
Мне надо сделать, чтоб система работала.
Я так сделал.
Других задач у меня нет. :-)
> Нет ни одной разумной причины использовать
> POP3 вместо IMAP4 (даже миф про разницу в
> потреблении трафика оказался мифом), ровно
> так же как и нет ни одной разумной причины
> использовать EventStream вместо WebSocket.
Для настройки WebSocket в браузере хорошие описания по интернетам существуют.
А для настройки серверной стороны хороших описаний, показывающих простоту настройки, нет.
Вот загрузилась, например, в браузер страница с веб-сервера Апач.
Из страницы с помощью WebSocket отправляется по некому адресу запрос на установку соединения.
Пока всё хорошо, т.к. действия из пары предыдущих предложений выполнить очень легко.
Дальше начинается что-то мало понятное:
Кто на сервере должен принять запрос на установку соединения WebSocket?
Ну первоначально-то запрос может принять и Апач: ну, например, Апач принял запрос, отдал его обработку моему перл-скрипту, который выдал правильные заголовки, включающие Upgrade и т.п.
А дальше что да как?
В обычной системе браузер отсылает запросы на веб-сервер отдельными подключениями и веб-сервер даёт на них ответы, после чего соединение сразу же закрывается.
А когда соединение из браузера по протоколу WebSocket установлено и является продолжительным, то кто на сервере может это соединение держать и работать с ним? Тут уже хорошие примеры по интернетам на глаза не попадаются.
Кто-нибудь может по шагам описать простую и понятную схему настройки серверной части для работы с WebSocket?
