13 534
правки
Изменения
Новая: В статье рассматриваются платформы/библиотеки для запуска веб-приложений на языке Perl. Все они деля...
В статье рассматриваются платформы/библиотеки для запуска веб-приложений на языке [[Perl]].
Все они делятся на две категории — библиотеки, дающие возможность запуска Standalone демона, и интерфейсы, требующие для работы внешнего веб HTTP-сервера.
== Требующие внешнего HTTP-сервера ==
=== CGI ===
Старый добрый Common Gateway Interface ([[rupedia:CGI|CGI]] — статья в русскоязычной Википедии), впервые реализованный где-то в районе 1993 года в первом HTTP-сервере [[rupedia:NCSA_HTTPd|NCSA HTTPd]] 1.0. Идея — максимально простой интерфейс взаимодействия с программой — через переменные окружения, а также стандартные ввод и вывод (STDIN и STDOUT). Веб-сервер при каждом запросе, который нужно обработать CGI приложением, запускает новый процесс (это самое приложение), передавая некоторые заголовки и данные в переменных окружения, а адрес запроса и содержимое (например, загружаемого на сервер файла) через стандартный ввод, после чего читает ответ (заголовки и содержимое) со стандартного вывода приложения.
Плюсы:
# Универсальность — скрипт, написанный с использованием [http://search.cpan.org/perldoc?CGI CGI.pm], будет работать на любой платформе, так как CGI поддерживают все (почти все?).
# Простые вещи реализовать на CGI просто. Чем-то эта идеология похожа на идеологию Perl в целом — простые задачи он делает простыми, а сложные — возможными.
# Большое количество наработок, то есть, модулей для работы в CGI среде.
# Запуск нового интерпретатора, помимо минуса (1), означает и плюс — свободу от свойственных долгоживущим Perl демонам утечек памяти.
А вот универсальность CGI в смысле возможности использования произвольного языка программирования для нас ни плюсом, ни минусом, очевидно, не является, так как рассматривается именно Perl.
Минусы:
# Самый очевидный и повторяемый всеми аки мантра минус — слабая производительность из-за необходимости запуска нового процесса интерпретатора при каждом запросе. Причин две — во-первых, это постоянно создаваемые процессы, которые могут быть совсем не лёгкими — раз, и вообще ограничивать производительность ОС большим числом переключений при большой нагрузке; во-вторых, это постоянные компиляции и инициализации модулей, занимающие приличное время.
# Кривой и устаревший код многих модулей для работы с разными функциями CGI. Примеры:
#* CGI.pm написан без использования <code>use strict</code>. Это не страшно, но показатель раздолбайства авторов.
#* В районе года 2000-ного авторам CGI.pm вдруг взбрело в голову, что век амперсанда (&) в качестве разделителя параметров в строках запроса подошёл к концу, и что теперь все будут использовать вместо него точку с запятой (;). Соответственно поведение и разбора, и генерации URL изменилось — причём, если в случае с генерацией всё легко возвращается на свои места заданием опции -oldstyle_urls, то разбор URL неизменно разбивает их и по «&», и по «;», что влечёт за собой различные неприятные эффекты.
#* Многие модули CGI::''xx'' исповедуют генерацию HTML кода без использования шаблонизаторов, обычными print()'ами, на содержимое которых повлиять без влезания в сами модули невозможно. ''XXI век на дворе, пора бы прекратить хотя бы это'' — ан нет, и в 2004, и даже в 2006 годах точно появлялись такие модули.
# Идеология CGI хоть чем-то и похожа на Перл, но фактически CGI больше рассчитан на простые задачи, нежели чем на сложные.
# Слабые возможности взаимодействия с HTTP-сервером — например, обычно в CGI даже не передаются все заголовки запроса. Кроме того, вывод ответа на STDOUT неудобен, если различные параметры задаются в различных местах программы.
=== FastCGI ===
=== mod_perl ===
=== ngx_http_perl_module ===
== Standalone ==
=== LWP (HTTP::Daemon) ===
=== HTTP::Server::Simple ===
[[Категория:Sway]]
[[Категория:Разработка]]
Все они делятся на две категории — библиотеки, дающие возможность запуска Standalone демона, и интерфейсы, требующие для работы внешнего веб HTTP-сервера.
== Требующие внешнего HTTP-сервера ==
=== CGI ===
Старый добрый Common Gateway Interface ([[rupedia:CGI|CGI]] — статья в русскоязычной Википедии), впервые реализованный где-то в районе 1993 года в первом HTTP-сервере [[rupedia:NCSA_HTTPd|NCSA HTTPd]] 1.0. Идея — максимально простой интерфейс взаимодействия с программой — через переменные окружения, а также стандартные ввод и вывод (STDIN и STDOUT). Веб-сервер при каждом запросе, который нужно обработать CGI приложением, запускает новый процесс (это самое приложение), передавая некоторые заголовки и данные в переменных окружения, а адрес запроса и содержимое (например, загружаемого на сервер файла) через стандартный ввод, после чего читает ответ (заголовки и содержимое) со стандартного вывода приложения.
Плюсы:
# Универсальность — скрипт, написанный с использованием [http://search.cpan.org/perldoc?CGI CGI.pm], будет работать на любой платформе, так как CGI поддерживают все (почти все?).
# Простые вещи реализовать на CGI просто. Чем-то эта идеология похожа на идеологию Perl в целом — простые задачи он делает простыми, а сложные — возможными.
# Большое количество наработок, то есть, модулей для работы в CGI среде.
# Запуск нового интерпретатора, помимо минуса (1), означает и плюс — свободу от свойственных долгоживущим Perl демонам утечек памяти.
А вот универсальность CGI в смысле возможности использования произвольного языка программирования для нас ни плюсом, ни минусом, очевидно, не является, так как рассматривается именно Perl.
Минусы:
# Самый очевидный и повторяемый всеми аки мантра минус — слабая производительность из-за необходимости запуска нового процесса интерпретатора при каждом запросе. Причин две — во-первых, это постоянно создаваемые процессы, которые могут быть совсем не лёгкими — раз, и вообще ограничивать производительность ОС большим числом переключений при большой нагрузке; во-вторых, это постоянные компиляции и инициализации модулей, занимающие приличное время.
# Кривой и устаревший код многих модулей для работы с разными функциями CGI. Примеры:
#* CGI.pm написан без использования <code>use strict</code>. Это не страшно, но показатель раздолбайства авторов.
#* В районе года 2000-ного авторам CGI.pm вдруг взбрело в голову, что век амперсанда (&) в качестве разделителя параметров в строках запроса подошёл к концу, и что теперь все будут использовать вместо него точку с запятой (;). Соответственно поведение и разбора, и генерации URL изменилось — причём, если в случае с генерацией всё легко возвращается на свои места заданием опции -oldstyle_urls, то разбор URL неизменно разбивает их и по «&», и по «;», что влечёт за собой различные неприятные эффекты.
#* Многие модули CGI::''xx'' исповедуют генерацию HTML кода без использования шаблонизаторов, обычными print()'ами, на содержимое которых повлиять без влезания в сами модули невозможно. ''XXI век на дворе, пора бы прекратить хотя бы это'' — ан нет, и в 2004, и даже в 2006 годах точно появлялись такие модули.
# Идеология CGI хоть чем-то и похожа на Перл, но фактически CGI больше рассчитан на простые задачи, нежели чем на сложные.
# Слабые возможности взаимодействия с HTTP-сервером — например, обычно в CGI даже не передаются все заголовки запроса. Кроме того, вывод ответа на STDOUT неудобен, если различные параметры задаются в различных местах программы.
=== FastCGI ===
=== mod_perl ===
=== ngx_http_perl_module ===
== Standalone ==
=== LWP (HTTP::Daemon) ===
=== HTTP::Server::Simple ===
[[Категория:Sway]]
[[Категория:Разработка]]
