Думаю, под борьбой подразумевались попытки одного вируса нейтрализовать другой. И да, в многозадачных системах с одним одноядерным процессором ничего «одновременно» также не выполняется
Вы продолжаете путать CGI и CGI.pm (+ другие модули). Для конечного приложения CGI — это только то, что в %ENV лежат переменные окружения, а в STDIN — input stream. При использовании PSGI переменные окружения лежат в первом параметре функции (пусть будет $env), input stream — в $env->{'psgi.input'}. Эти различия можно устранить и использовать CGI.pm в PSGI-приложении, если вам так хочется. Пруф:
use CGI::Stateless;
sub {
my $env = shift;
local *STDIN; open STDIN, '<', $env->{'psgi.input'};
local %ENV = %{$env};
local $CGI::Q = new CGI::Stateless;
Вы путаете CGI и CGI.pm. CGI — протокол, CGI.pm — это тоже своего рода абстракция (над тремя способами подключения — СGI, FCGI и mod_perl), плюс огромное количество в большинстве своем ненужных функций.
Если вы говорите про CGI как способ подключения, а не про CGI.pm, то это не абстракция, а один из протоколов, над которым PSGI является асбтракцией.
Если вы сравниваете интерфейсы, предоставляемые конечному приложению, то они сильно похожи (также используются переменные окружения, и имена у них одинаковые).
Если так судить, то и DBI не нужен — все равно в проекте будет использоваться только одна СУБД, зачем лишний слой абстракции?
Как минимум, такой подход нельзя использовать для фреймворков. Нельзя сказать, как программист захочет запускать приложение на фреймворке. Поэтому в каталисте, например, 4 разных файла для запуска приложения четырьмя разными способами (httpd, cgi, fcgi, mod_perl). В другом фреймворке эта проблема может быть решена по другому. Но такого бы не было, если бы существовал единый стандарт для подключения — теперь он есть.
Видимо, вы имеете в виду CGI::param — это функция из модуля CGI.pm. Это уже не логика взаимодействия с сервером и даже не касается собственно интерфейса CGI.
чтением/установке кукисов — что делает обычно менеджер сессий и что непонятно как делает PSGI
Это тем более не задача интерфейса. Менеджер сессий, урл-диспатчер — это должно реализовываться во фреймворке.
Отделять бизнес-логику от взаимодействия с сервером позволяет Catalist
В Catalyst эта задача решена использованием HTTP::Engine — решение хорошее, на нем отдельно остановились в PSGI::FAQ — можно почитать по ссылке в статье.
CGI интерфейс задаётся браузером
Дальше не читал
Ещё можно почитать этот комментарий. PSGI — это интерфейс, а не фреймворк или что-либо ещё. Такой же интерфейс, как DBI или AnyEvent.
Такое, что, к примеру, в веб-приложениях принято отделять логику отображения от бизнес-логики. PSGI позвоялет отделить бизнес-логику от логики взаимодействия с http-сервером.
AnyEvent — абстракция для event loop, дающая единый интерфейс для программ, использующих event loop, сохраняющая возможность использовать любой event loop (EV, IO::Async), для которого есть поддержка. Чтобы многочисленные модули (AnyEvent::XMPP, AnyEvent::IRC) можно было писать для этой абстракции, а не для конкретного event loop.
DBI — абстракция над функциями работы с СУБД, дающая единый интерфейс для программ, взаимодействующих с СУБД, сохраняющая возможность использовать любую СУБД (MySQL, PostgreSQL), для которой есть поддержка. Чтобы многочисленные модули (DBIx::Class, Catalyst::Model::DBI) можно было писать для этой абстракции, а не для конкретной СУБД.
PSGI — абстракция для способов подключения веб-приложений к http-серверу, сохраняющая возможность использовать любой способ подключения (mod_perl, FastCGI), для которого есть поддержка. Чтобы многочисленные веб-приложения и веб-фреймворки можно было писать для этой абстракции, а не для конкретного способа подключения.
Для меня лично профит в том, что вообще не нужно думать о способе подключения приложения к серверу — это чужая проблема, разработчику приложения нужно писать бизнес-логику приложения. Абсолютно прозрачно можно сменить способ подключения с CGI на FCGI, SCGI, mod_perl, whatever — лишь бы способ подключения удовлетворял требованиям приложения (если приложение может работать только при определенном значении переменных окружения psgi.*)
Сам лично PSGI/Plack не использовал, ибо увидел недавно, но хочу попробовать написать PSGI-сервер для моего AnyEvent::FCGI
1) да, складывать их в очередь ровно также как на сервере
2) да, сразу. после этого сразу посылается следующий запрос, только после окончания предыдущего. то есть в любой момент времени может быть не больше одного читающего с сервера данные запроса. А со стороны клиента в текущей реализации два подряд быстро отправленных сообщения уйдут на сервер в параллельных запросах, и не факт что первое придет раньше :)
Гарантированная доставка возможно в случае отправки клиентом подтверждения о доставке нумеровннаых сообщений.
Race condition может быть только в исходящих от клиента запросов. Сообщения с сервера забираются одним запросом, и следующий запрос не будет создан пока не будет получен ответ на предыдущий.
Вы, видимо, меня не поняли :) Мой перловый сервер имеет ровно ту же архитектуру, что и nginx — конечный автомат на асинхронных сокетах, и так же как и nginx, может обрабатывать тысячи подключений (от nginx'а). Причины, по которым я вставил посередине nginx, я описал в статье. В принципе, можно его легко убрать и просто заменить AnyEvent::FCGI на AnyEvent::HTTPD и работать напрямую с клиентом — ничего не изменится. Для вас, наверное, впечатление о перле сложилось в те времена, когда на нем ничего кроме CGI-приложений под веб не делали. Рекомендую почитать мою предыдущую статью, ссылка в этом посте :)
Если вы сравниваете интерфейсы, предоставляемые конечному приложению, то они сильно похожи (также используются переменные окружения, и имена у них одинаковые).
Как минимум, такой подход нельзя использовать для фреймворков. Нельзя сказать, как программист захочет запускать приложение на фреймворке. Поэтому в каталисте, например, 4 разных файла для запуска приложения четырьмя разными способами (httpd, cgi, fcgi, mod_perl). В другом фреймворке эта проблема может быть решена по другому. Но такого бы не было, если бы существовал единый стандарт для подключения — теперь он есть.
Видимо, вы имеете в виду CGI::param — это функция из модуля CGI.pm. Это уже не логика взаимодействия с сервером и даже не касается собственно интерфейса CGI.
Это тем более не задача интерфейса. Менеджер сессий, урл-диспатчер — это должно реализовываться во фреймворке.
В Catalyst эта задача решена использованием HTTP::Engine — решение хорошее, на нем отдельно остановились в PSGI::FAQ — можно почитать по ссылке в статье.
Дальше не читал
Ещё можно почитать этот комментарий. PSGI — это интерфейс, а не фреймворк или что-либо ещё. Такой же интерфейс, как DBI или AnyEvent.
DBI — абстракция над функциями работы с СУБД, дающая единый интерфейс для программ, взаимодействующих с СУБД, сохраняющая возможность использовать любую СУБД (MySQL, PostgreSQL), для которой есть поддержка. Чтобы многочисленные модули (DBIx::Class, Catalyst::Model::DBI) можно было писать для этой абстракции, а не для конкретной СУБД.
PSGI — абстракция для способов подключения веб-приложений к http-серверу, сохраняющая возможность использовать любой способ подключения (mod_perl, FastCGI), для которого есть поддержка. Чтобы многочисленные веб-приложения и веб-фреймворки можно было писать для этой абстракции, а не для конкретного способа подключения.
www.simon-cozens.org/content/i-finally-get-psgi-and-plack
Для меня лично профит в том, что вообще не нужно думать о способе подключения приложения к серверу — это чужая проблема, разработчику приложения нужно писать бизнес-логику приложения. Абсолютно прозрачно можно сменить способ подключения с CGI на FCGI, SCGI, mod_perl, whatever — лишь бы способ подключения удовлетворял требованиям приложения (если приложение может работать только при определенном значении переменных окружения psgi.*)
Сам лично PSGI/Plack не использовал, ибо увидел недавно, но хочу попробовать написать PSGI-сервер для моего AnyEvent::FCGI
2) да, сразу. после этого сразу посылается следующий запрос, только после окончания предыдущего. то есть в любой момент времени может быть не больше одного читающего с сервера данные запроса. А со стороны клиента в текущей реализации два подряд быстро отправленных сообщения уйдут на сервер в параллельных запросах, и не факт что первое придет раньше :)
foreach my $user (keys %users) {
push_actions(
$user,
# действия для рассылки
);
}
Для приватного сообщения можно вызвать push_actions не для всех, а только для того, для кого надо :)
1) питон я не знаю
2) мне хотелось написать
велосипедсвою реализацию, чтобы понять технологию и получить новый опытИз готовых решений на перле можно посмотреть Stardust — «the simplest COMET server»
Race condition может быть только в исходящих от клиента запросов. Сообщения с сервера забираются одним запросом, и следующий запрос не будет создан пока не будет получен ответ на предыдущий.