На последнем заседании управляющего комитета организации Apache Software Foundation принято решение (http://blog.dscpl.com.au/2010/06/modpython-project-is-now-of...) признать устаревшим проект Apache Quetzalcoatl (http://attic.apache.org/projects/quetzalcoatl.html), в рамках которого велась разработка Apache-модуля mod_python (http://www.modpython.org/), обеспечивающего интеграцию интерпретатора Python в Apache и позволяющего реализовать в скриптах низкоуровневые обработчики запросов. Все связанные mod_python разработки перемещены в репозиторий устаревших проектов Apache Attic (http://attic.apache.org/).
Последний релиз mod_python вышел в начале 2007 года, после чего разработка проекта остановилось, а разработчики переключились на развитие mod_wsgi (http://code.google.com/p/modwsgi/). Более того, в последние годы из-за ошибки в коде mod_python, данный модуль не мог функционировать совместно с последними версиями http-сервера Apache 2.2/2.4 без наложения дополнительных п...URL: http://blog.dscpl.com.au/2010/06/modpython-project-is-now-of...
Новость: http://www.opennet.me/opennews/art.shtml?num=27087
Осталось для апача сделать нормальный модуль FastCGI под свободной лицензией, и mod_wsgi тоже можно зарывать.Впрочем, и апач скоро можно зарывать, легковесные серверы этот мотокомбайн потихоньку теснят.
Вроде с точностью наоборот. Когда допилят mod_wsgi то это старье FastCGI нужно
закапывать ...
mod_wsgi работает только с питоном, и то не без проблем. Т. к. встраивать интерпретатор не самого легковесного языка в в HTTP-сервер - то ещё решение. Это уже Windows-way какой-то. Вдобавок, оказывается, что среда выполнения в продакшене сильно отличается от среды выполнения у разработчика на машине, где всё запускается через /usr/bin/env python. Ина регулярно вылезают на боевом сервере mod_wsgi-специфичные глюки, которые в процессе разработки невозможно было отловить. Погуглите xapian mod_wsgi, например - тикет открыт с 2007 года.А FastCGI работает везде и всегда, с любыми языками и фреймворками. В случае питона всё запускается через тот же самый /usr/bin/python, что и всегда. Разница в производительности с mod_wsgi - на уровне погрешности. Так что я вообще не понимаю, зачем этот mod_wsgi нужен.
> Т. к. встраивать интерпретатор не самого легковесного языка в в HTTP-серверТе нужно выкинуть mod_php и заменить его на php-cgi ? ;)
Ну лично я - уже. Заодно значительно разгрузил сервера.
>Заодно значительно разгрузил сервера.от посетителей? :)
>> Т. к. встраивать интерпретатор не самого легковесного языка в в HTTP-сервер
>
>Те нужно выкинуть mod_php и заменить его на php-cgi ? ;)Ни раз встречал статьи о развеивании мифов о том, что php-cgi якобы быстрее mod_php.
>Ни раз встречал статьи о развеивании мифов о том, что php-cgi якобы
>быстрее mod_php.Не путайте сам со себе php-cgi, работающий как обычный CGI-скрипт, с запуском PHP под управлением FastCGI.
FastCGI достаточно простая и прозрачная технология, трудно придумать ситуацию, когда mod_php может оказаться быстрее. Но эта простота в FastCGI выливается иногда в значительный недостаток, делающим его уделом standalone-проектов и мешающим его использованию в системах с несколькими сайтами/пользователями или когда у проекта много разных скриптов. FastCGI не для массовых систем, а для отдельных крупных проектов.
> Но эта простота в FastCGI выливается иногда в значительный
>недостаток, делающим его уделом standalone-проектов и мешающим его использованию в >системах с несколькими сайтами/пользователями или когда у проекта много разных скриптов. >FastCGI не для массовых систем, а для отдельных крупных проектов.php-fpm решает некоторые из этих проблем. Правда, в основном ценой снижения простоты.
Что мешает использовать FactCGI для массовых систем?
> Что мешает использовать FactCGI для массовых систем?разделение привелегий (разных пользователей хостинга) мешает:
для каждого пользователя Апача -- потребуется запускать (и держать в памяти сервера даже когда это не нада) -- загружанные копии php-cgi-процессов...
..чем больше пользователей хостинга, тем больше php-cgi-процессов.
в случае с mod_php -- отдельные [изолированные в своих привелегиях] процессы для обработки PHP-файлов -- сами запускаются для каждого из пользователей Апача, и сами закрываются, когда они некоторое время не требуются
>разделение привелегий (разных пользователей хостинга) мешает:Shared хостинги вообще строго говоря большие помойки, которые должны умереть. Уж простите за правду. Но достаточно просто почитать какойнить хацккер.ру или что там еще с кульхаксорами чтобы узреть как они поимели сайт приличной конторы только потому что он хостился там же где и сайт В. Пупкина. При том имели и сайты довольно приличных контор у довольно защищенных хостеров (в этом месте в голову пришло слово мастерхост например)
>для каждого пользователя Апача -- потребуется запускать (и держать в памяти сервера
>даже когда это не нада) -- загружанные копии php-cgi-процессов...Неудобно для помоек, какая жалость ;(. Только сами эти помойки - маздай и прошлый век, по большому счету. Уж как минимум вдсник/виртуалка для НОРМАЛЬНОЙ изоляции от юных сракеров и пионеров - просто must have, имхо. Явно более внушает доверие, если уж о привилегиях спич. И при этом однофигственно будет своя копия сервера с своей собственной конфигурацией, и что характерно - спрос на именно это весьма возрос в последнее время судя по всему.
>> Что мешает использовать FactCGI для массовых систем?
>
>разделение привелегий (разных пользователей хостинга) мешает:
>
>для каждого пользователя Апача -- потребуется запускать (и держать в памяти сервера
>даже когда это не нада) -- загружанные копии ...
>
>..чем больше пользователей хостинга, тем больше php-cgi-процессов.
>Вообщето php-cgi запускать на апаче через fastcgi это даже не смешно.
>в случае с mod_php -- отдельные [изолированные в своих привелегиях]
А вот и не изолированные.
> процессы для
>обработки PHP-файлов -- сами запускаются для каждого из пользователей Апача, и
>сами закрываются, когда они некоторое время не требуютсяНа самом деле они закрываются сразу после того, как обработали запрос.
Совершенно верно. На php-fpm, если быть точным.
> mod_wsgi работает только с питоном, и то не без проблем. Т. к. встраивать интерпретатор не самого легковесного языка в в HTTP-сервер - то ещё решение. Это уже Windows-way какой-то.Хм. Интересно, а Перл - легковесный язык?
А с чем вы сравниваете? В принципе, довольно легковесный. Возьму на себя смелость предположить, что легче Python-а и PHP.Главные затраты приходятся на запуск интерпретатора. Когда он уже загружен, программы на Perl интерпретируются очень быстро.
Я думаю, именно это позволило встроить Perl в такие программы, как Exim и nginx. Отметим, что в nginx он по-умолчанию не ставится, что и понятно. Не во всех случаях возможности Perl нужны.
>mod_wsgi работает только с питоном, и то не без проблем. Т. к.встраивать интерпретатор не самого легковесного языка в в HTTP-сервер - то ещё решение. Это уже Windows-way какой-то.А теперь покажи нам _ГДЕ_ же в коде mod_wsgi ты нашёл Python?!?!
Ыксперты жгутЪ, ага ...
>>mod_wsgi работает только с питоном, и то не без проблем. Т. к.встраивать интерпретатор не самого легковесного языка в в HTTP-сервер - то ещё решение. Это уже Windows-way какой-то.
>
>А теперь покажи нам _ГДЕ_ же в коде mod_wsgi ты нашёл Python?!?!
>
>
>Ыксперты жгутЪ, ага ...Похоже, тут: http://ru.wikipedia.org/wiki/Mod_wsgi http://ru.wikipedia.org/wiki/WSGI
>>>mod_wsgi работает только с питоном, и то не без проблем. Т. к.встраивать интерпретатор не самого легковесного языка в в HTTP-сервер - то ещё решение. Это уже Windows-way какой-то.
>>
>>А теперь покажи нам _ГДЕ_ же в коде mod_wsgi ты нашёл Python?!?!
>>
>>Ыксперты жгутЪ, ага ...
>
>Похоже, тут: http://ru.wikipedia.org/wiki/Mod_wsgi http://ru.wikipedia.org/wiki/WSGIНе читайте советских газет!(С)Пр. Преображенский
Не читайте русскую вику, особенно если не понимаете русский. Впрочем даже там в самом внизу есть ссылка на сайт mod_wcgi, где ангельскими буЦквами написано:
The mod_wsgi module is written in C code directly against the internal Apache and Python application programming interfaces. As such, for hosting WSGI applications in conjunction with Apache it has a lower memory overhead and performs better than existing WSGI adapters for mod_python or alternative FASTCGI/SCGI/CGI or proxy based solutions.Ну и много другого интересного.
Ты чудо, речь была о том, что mod_wsgi линкуется с питоньим рантаймом и запускает питоний интерпретатор прямо из апачевских процессов.
> Не читайте русскую вику, особенно если не понимаете русский.Не учите других, на каком языке читать, если не можете прочесть программный код.
> The mod_wsgi module is written in C
Видимо это единственная фраза, смысл которой вам удалось понять, и которая вас сподвигла на следующее революсьЕное заявление.
> А теперь покажи нам _ГДЕ_ же в коде mod_wsgi ты нашёл Python?!?!
Ну так вы сами же и показали, где в коде mod_wsgi находится Python.
> directly against the internal Apache and Python application programming interfaces.
А теперь все вместе.
> The mod_wsgi module is written in C code directly against the internal Apache and Python application programming interfaces.
Python API - это и есть Python практически один в один, только на языке С.
Вам только остается понять, как такое может быть. Вот для этого как раз и нужно знать языки программирования, а не только английский, знанием которого вы так гордитесь.
>>mod_wsgi работает только с питоном, и то не без проблем. Т. к.встраивать интерпретатор не
>самого легковесного языка в в HTTP-сервер - то ещё решение. Это уже Windows-way какой-то.
>А теперь покажи нам _ГДЕ_ же в коде mod_wsgi ты нашёл Python?!?!Протокол WSGI - откровенно ориентирован на питон, если мне склероз не изменяет. И уж не этот ли протокол случайно Сысоев назвал удивительным по степени дебильности? Или его соседа, который не сильно от него отличается.
ага: http://www.opennet.me/openforum/vsluhforumID3/67791.html#7
>>>встраивать интерпретатор не самого легковесного языка
>>>в в HTTP-сервер - то ещё решение.
>>А теперь покажи нам _ГДЕ_ же в коде mod_wsgi ты нашёл Python?!?!
>Протокол WSGI - откровенно ориентирован на питон,Я с этим и не спорю. Вот только сам mod_wsgi написан на чистом таком С :)
>если мне склероз не изменяет. И уж не этот ли протокол случайно
>Сысоев назвал удивительным по степени дебильности?Не изменяет - его! И по делу.
Но если честно - а много ли вообще не дебильных протоколов? :)
Ну и самое главное - лучше уж дебильноватый, но стандарт, чем каждый свое "не имеющее аналогов" ...
>>Протокол WSGI - откровенно ориентирован на питон,
>Я с этим и не спорю.Да уж, учитывая расплывчатось формулировки "ориентирован на питон", здесь как раз можно было и поспорить. Поскольку может ведь случиться так, что написано на Питоне, но на Питон не ориентировано. А может быть написано на С, а все равно получается "чистый такой Python".
>Вот только сам mod_wsgi написан на чистом таком С :)
Вот как раз и интересно, что такое в вашем понимании "чистый такой С". И какой С в вашем понимании может тогда быть не чистым.
И самое главное, что по-вашему это меняет, если там "чистый такой С", но все равно "directly against the internal <...> Python application programming interfaces", как вы сами это процитировали выше.
> Ну и самое главное - лучше уж дебильноватый, но стандарт, чем каждый свое "не имеющее аналогов" ...
Может лучше, а может хуже. Только чтобы делать подобные заявления нужно в этом разбираться. А вы уровень своих познаний уже показали. Так что просто тыкаете пальцем в небо рассуждая, что лучше, а что хуже.
"Протокол WSGI" - это название стандартного API Питона для взаимодействия с веб-сервером. Полное название - "Python Web Server Gateway Interface". Отдельно от Питона WSGI существовать не может, т. к. весь протокол по сути - описание некоторых соглашений о вызове функций на Питоне. Оринигал спецификации здесь: http://www.python.org/dev/peps/pep-0333///Ваша Бабушка
Чей стандарт? Питона? Ну так пусть он его и мучает.Вам надо еще и понятие слова "стандарт" разжевать.
Удачи в познании "великого и могучего"
//Как видно ваша бабушка произошла от вашего дедушки путем хирургическим манипуляций.
>//Ваша Бабушкабабушка, у вас маразм. уродливый питонский протокол - это питонская личная суксуальная драма, всем наплевать. только не надо впердоливать в и без того толстого индейца десяток ужратых питонов
>Я с этим и не спорю. Вот только сам mod_wsgi написан на
>чистом таком С :)Питон тоже на C написан, IIRC. Но сями не является. Хоть и может юзать сишные либы как я понимаю.
>Не изменяет - его! И по делу.
:-)
>Но если честно - а много ли вообще не дебильных протоколов? :)
Честно? Немного. Весьма. Почему-то большая часть протоколов - именно дебильные (звучит почти как "все пи...сы", но ведь правда же! :D).
>Ну и самое главное - лучше уж дебильноватый, но стандарт, чем каждый
>свое "не имеющее аналогов" ...А еще лучше - не дебильноватый и стандарт. Я слишком многого хочу в этой жизни? Или стандарт по какому-то неведомому закону природы просто обязан быть дебильным и отстойным, чтобы кому-то зудело в нижней части спины сделать лучше? :)
>>>mod_wsgi работает только с питоном, и то не без проблем. Т. к.встраивать интерпретатор не
>>самого легковесного языка в в HTTP-сервер - то ещё решение. Это уже Windows-way какой-то.
>>А теперь покажи нам _ГДЕ_ же в коде mod_wsgi ты нашёл Python?!?!
>
>Протокол WSGI - откровенно ориентирован на питон, если мне склероз не изменяет.
>И уж не этот ли протокол случайно Сысоев назвал удивительным по
>степени дебильности? Или его соседа, который не сильно от него отличается.
>WSGI Это не протокол. Удивительным по степени идиотизма он назвал uWSGI, но это резковато сказано.
>Протокол WSGI - откровенно ориентирован на питон, если мне склероз не изменяет.Ровно в той же мере, что и CGI на PHP или Perl. Проще говоря этот протокол был разработан в Python community, но под Python он ни разу завязан. Просто 99% реализаций этого протокола написаны на Python. Но написать реализацию под например Perl вам ничто не мешает.
>И уж не этот ли протокол случайно Сысоев назвал удивительным по
>степени дебильности?Нет, не его. Ему не нравится uWSGI, который с протоколом WSGI имеет не очень многое. Собственно говоря модуль для nginx написан на основе модуля FastCGI. И к FastCGI/SCGI и другим подобным протоколам у Игоря примерно такие же претензии.
> Или его соседа, который не сильно от него отличается.
Отличается и ОЧЕНЬ сильно. Общее по сути только в названии.
>Проще говоря этот протокол был разработан в Python community, но под
>Python он ни разу завязан. Просто 99% реализаций этого протокола написаны
>на Python. Но написать реализацию под например Perl вам ничто не
>мешает.Ну елки зеленые.
WSGI это не протокол, это стандарт взаимодействия python приложения с http сервером.
python и только.
> Впрочем, и апач скоро можно зарывать, легковесные серверы этот мотокомбайн потихоньку теснят.Ври, ври, да не перевирай... Или же ссылки в студию.
>Ври, ври, да не перевирай... Или же ссылки в студию.То, что сейчас можно найти по ссылкам, которых вы требуете - это инерция. Люди как научились ставить "опаче" и писать под него программы с использованием .htaccess и .htpasswd, так и продолжают. И именно эта инерция и мешает занять другим веб-серверам его место.
>>Ври, ври, да не перевирай... Или же ссылки в студию.
>
>То, что сейчас можно найти по ссылкам, которых вы требуете - это
>инерция. Люди как научились ставить "опаче" и писать под него программы
>с использованием .htaccess и .htpasswd, так и продолжают. И именно эта
>инерция и мешает занять другим веб-серверам его место.Да еще и куча CMS с обязательной поддержкой Apache (читай ".htaccess").
>>Ври, ври, да не перевирай... Или же ссылки в студию.
>
>То, что сейчас можно найти по ссылкам, которых вы требуете - это
>инерция. Люди как научились ставить "опаче" и писать под него программы
>с использованием .htaccess и .htpasswd, так и продолжают. И именно эта
>инерция и мешает занять другим веб-серверам его место.Люди научились писать... программы? Под apache? C использованием .htaccess???
А есть какой-нибудь столь же стабильный, удобный и функциональный конкурент для Apache кстати?
>А есть какой-нибудь столь же стабильный, удобный и функциональный конкурент для Apache кстати?Ну если конкретно для вас Apache - самый "стабильный, удобный и функциональный", то зачем других то по себе судить.
Стабильность - смотря какой ценой она достигается. А Вы считаете, что Apache хотя бы по стабильности вне конкуренции? Ну ваше право так считать.
Удобство - чисто субъективная характеристика.
Функционал. Вы считате, что для разработчика важнее готовый "функционал", чем средства для создания функционала? Если так, то вы скорее не разработчик, а просто "продвинутый юзер", чуть более, чем собиратель юзер-интерфейсов "из кубиков".
> И именно эта инерция и мешает занять другим веб-серверам его место.Ойданупрям.
Апач -- это платформа, nginx -- это заточенный под сознательно более узкий круг задач сервер. Разницу, думаю, сами понимаете.
>Ойданупрям.
>
>Апач -- это платформа, nginx -- это заточенный под сознательно более узкий круг задач сервер. Разницу, думаю, сами понимаете.Когда не знают, что сказать, говорят "платформа".
И что же по-вашему мешает быть какой-то "платформе" быть "сознательно заточенной" под более узкий круг задач?
И что, с другой стороны, по-вашему в Апаче больше "платформенного", чем в других?А на самом деле, просто как все поклонники ширпотреба, вы путаете широту "круга задач" с количеством потребителей и популярностью.
Хотя обычно зависимоть обратная. Чем больше потребителей, тем меньший "круг задач" они способны решать в виду шаблонности своего мышления и похожести друг на друга.
>Когда не знают, что сказать, говорят "платформа".и ведь правда!
(конешно щаз уйду в offtop, но немогу этого не добавить :))
в русской документации (MSDN) по .NET -- слово "Framework" с англисского-на-русский везде перевели как "платформа".
а всё потомучто переводчики не знали что ещё и в русском языке есть слово "програмный каркас"
>>Апач -- это платформа
>Когда не знают, что сказать, говорят "платформа".Ясно, не понимаете. Попробую на пальцах.
Платформа (когда слово применено по назначению) -- это не самоценность, а то, ценность чего обуславливается возможностью надстраиваться сверху. Что железобетонная, что программная.
>И что, с другой стороны, по-вашему в Апаче больше "платформенного", чем в
>других?Он стал "домом" для множества сторонних разработчиков модулей, приносящих дополнительную функциональность итоговому продукту. Назовите другой httpd с сопоставимым выбором модулей (или иначе -- доступной в пределе функциональности), чтоб не бегать за неопределёнными другими. Я другого такого попросту не знаю, потому и интересуюсь.
>И что же по-вашему мешает быть какой-то "платформе" быть "сознательно заточенной"
>под более узкий круг задач?Ничто -- например, у апача рекордная производительность попросту сознательно не включена в задачи.
>А на самом деле, просто как все поклонники ширпотреба, вы путаете широту
>"круга задач" с количеством потребителей и популярностью.Глупенький, популярность свободных проектов (тем более не из модной эпохи) как раз и определялась применимостью и качеством. :) Поразмышляйте над тем, как NCSA httpd стал "a patchy httpd", что ли.
>Хотя обычно зависимоть обратная.
Это среди вас, любителей как раз ширпотреба.
PS: я до сих пор применяю и местами майнтейню apache-1.3 в альте, если что.
PPS: "a patchy server", во, вспомнил.
>я до сих пор применяю и местами майнтейню apache-1.3 в альте, если что.Надеюсь, всё у вас будет хорошо.
>>>Апач -- это платформа
>>Когда не знают, что сказать, говорят "платформа".
>
>Ясно, не понимаете. Попробую на пальцах.
>
>Платформа (когда слово применено по назначению) -- это не самоценность, а то, ценность чего обуславливается возможностью надстраиваться сверху. Что железобетонная, что программная.А ну с этой точки зрения конечно да.
Только в ИТ-мире в отличии от физического мира, сделать так, чтобы что-то настраивалось поверх чего-то не так уж сложно.И хорошей платформой является то, что изначально создавалось, как платформа. А не то, что выросло в платформу просто благодаря маркетинговому раскруту и разрастанию этого самого функционала, так любимого массами.
Вот я и говорю, что когда не знают, чем оправдаться, говорят - "Зато у нас платформа получилась, посмотрите сколько мы всего сверху понастраивали".
>>И что, с другой стороны, по-вашему в Апаче больше "платформенного", чем в других?
>
>Он стал "домом" для множества сторонних разработчиков модулей, приносящих дополнительную функциональность итоговому продукту. Назовите другой httpd с сопоставимым выбором модулей (или иначе -- доступной в пределе функциональности), чтоб не бегать за неопределёнными другими.Если в проектировании придерживаться UNIX-way, системного мышления и компонетного подхода со слабой связностью, то что угодно может без труда стать "домом" или платформой для чего угодно. Просто достаточно сменить угол зрения.
Это дискретное пространство, которое обладает нулевой мерностью. Здесь нет верха и низа, снаружи и внутри. Откуда хочешь, оттуда и "надстрайвай".
Только системное мышление крайне не популярно в широких массах. Потому и появляются всякие "платформы", тешащие массовые псевдо-материальные стереотипы. Ну и хорошо, меньшенству всегда достается самое лучшее.
> Я другого такого попросту не знаю, потому и интересуюсь.
Ну и хорошо, что другие веб-сервера по этому пути не пошли.
>Глупенький, популярность свободных проектов (тем более не из модной эпохи) как раз и определялась применимостью и качеством. :)
Да уж конечно. Все поклонники ширпотреба убеждены, что их любимое самое качественное и применимое, ведь оно такое функциональное и сверхунастраивоемое. Потому как сами функционал могут создавать только под копирку и по стандартам, а если им не показать, где "верх", сразу теряют ориентацию.
>Поразмышляйте над тем, как NCSA httpd стал "a patchy httpd", что ли.
>PS: я до сих пор применяю и местами майнтейню apache-1.3 в альте,
>если что.
>PPS: "a patchy server", во, вспомнил.Могу позволить себе не знать все детали развития сего творения. Я уже давно понял, что оно пошло в сторону от UNIX-way. Вам оно, как это видно, очень дорого, вот сами и размышляйте, как оно таким стало.
>>Да уж конечно. Все поклонники ширпотреба убеждены, что их любимое самое качественное и применимое, ведь оно такое функциональное и сверхунастраивоемое.*сверхунаДстраивоемое*
>>*сверхунаДстраивоемое**сверху-наДстраивАемое* - видимо даже так )))
>Только в ИТ-мире в отличии от физического мира, сделать так, чтобы что-то
>настраивалось поверх чего-то не так уж сложно.Пробовали?
>Это дискретное пространство, которое обладает нулевой мерностью.
>Здесь нет верха и низа, снаружи и внутри.Надо же, то есть термины вроде "высокоуровневое API", "низкоуровневый интерфейс", "публичный символ", "глубоко вложенный цикл" -- это всё от балды и для красивого словца, развенчанного Вашими строгими и притом изящными формулябрами?
>Откуда хочешь, оттуда и "надстрайвай".
Можно поинтересоваться Вашим опытом разработки, доработки и просто хаков по месту?
Мне вот за последние лет двадцать доводилось выбрасывать код, который в силу своей примитивности/узконаправленности попросту не годился под то, чтоб к нему хоть откуда-то, не говоря уж откуда хотелось бы, пристроиться.
Скажем для mc лет десять тому получилось изобразить на шелле VFS-ки для m3u и iso (последнюю приняли в апстрим потом), а вот для nc 2.x ничего подобного не получалось. Хотя в той же "нулевой мерности", если Вам верить.
>Ну и хорошо, меньшенству всегда достается самое лучшее.
МеньшИнству тоже достаётся. :)
Насчёт лучшего -- оно всегда субъективно.>> Я другого такого попросту не знаю, потому и интересуюсь.
>Ну и хорошо, что другие веб-сервера по этому пути не пошли.А этого и не требовалось, с апачем долгое время не было особого смысла конкурировать вообще. Разве что для более узких задач вроде статики+cgi и совсем уж минимальных ресурсов, на что давно сделаны boa, thttpd, mathopd.
С тех пор появились более шустрые userspace/kernelspace интерфейсы в доступных ОС, совсем изменилась картина по части параллелизма ширпотребных вычислений, сдвинулось равновесие между ресурсами на веб-сервер и на веб-приложение... много чего произошло такого, из-за чего сравниваете теперь тёплое с мягким.
Ну и напоминаю для коррекции нуля -- первый апач вполне работает на 486.
>>Глупенький, популярность свободных проектов (тем более не из модной эпохи)
>>как раз и определялась применимостью и качеством. :)
>Да уж конечно. Все поклонники ширпотреба убеждены, что их любимое самое качественное
>и применимое, ведь оно такое функциональное и сверхунастраивоемое.Мне только вещать вот это не надо, ага?
home:/var/ftp/pub/Linux/utils/web> ls -l | grep --with-brain
-rw-rw-r-- 1 mike mike 61670 Mar 23 1999 boa-0.92q.tar.gz
-rw-rw-r-- 1 mike mike 415624 Oct 23 1999 wn-2.0.10.tar.gz
-rw-rw-r-- 1 mike mike 96688 Oct 23 1999 xs-httpd.tar.gzЯ с ними работал, а boa и не так давно применял (пока nginx-0.1.x не вышел).
>Потому как сами функционал могут создавать только под копирку и по стандартам,
>а если им не показать, где "верх", сразу теряют ориентацию.Пустопорожняя болтовня и надувание щёк. Стыдно.
>Апач -- это платформа,Апач пытается быть всем и сразу. В итоге работая не особо эффективно и давно уже просрав основную идею юниксвея по части делания одной вещи и хорошо. Да, делает уйму всего. И в итоге - стало оно энтерпрайзным софтом. Со всеми вытекающими - как то монструозный переросток с уймой ненужных 90% юзерам фич, которые требуют тем не менее покупать могучие сервера для того с чем справился бы и селерон у Васи под шкафом.
Да netcraft хотя-бы. По-моему надо быть вообще не бум-бум в web технологиях чтобы не понимать очевидность этого процесса.
apache возможно сместят с front-end'a, но с обработкой кучи разных скриптов он пока неплохо справляется
Apache - это нечто среднее между веб-сервером и сервером приложений. Являясь одновременно и тем и другим, он одновременно проигрывает и веб-серверам и серверам приложений.
>Apache - это нечто среднее между веб-сервером и сервером приложений. Являясь одновременно
>и тем и другим, он одновременно проигрывает и веб-серверам и серверам
>приложений.Чем Апач вам напоминает сервер приложений?
mod_php и подобными, очевидно. А как фронтэнд и сервер статики он монструозен и неповоротлив. Достаточно посмотреть что втыкают реально нагруженные проекты для этих целей.
Джангокапец?
django работает с wsgi
да он и с FastCGI работает, как ни странно :-)
ну.... если сайт работает на WSGI, то ясное дело что он же работает: и с FastCGI, и с SCGI, и с CGI, ... и фиг ещё знает с чем :-)
А мне кажется, для WSGI просто выбрали неудачное название, потому все и его и ставят на одну полку с протоколами CGI и FastCGI. Хотя все три - совсем разные вещи, в одном случае интерфейс на уровне Питона, в другом - на уровне UNIX-like модели исполнения программ, а в третьем случае - вообще сокеты.Лучше бы назвали его Python Web API, по аналогии с Python DB API, и всё бы встало на свои места.
на самом деле -- думаю что только совсем малю людей путаются.....другие же вполне понимают что WSGI+SCGI вполне нормлаьный стэк :-)