The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Проект mod_python прекратил существование

24.06.2010 12:32

На последнем заседании управляющего комитета организации Apache Software Foundation принято решение признать устаревшим проект Apache Quetzalcoatl, в рамках которого велась разработка Apache-модуля mod_python, обеспечивающего интеграцию интерпретатора Python в Apache и позволяющего реализовать в скриптах низкоуровневые обработчики запросов. Все связанные mod_python разработки перемещены в репозиторий устаревших проектов Apache Attic.

Последний релиз mod_python вышел в начале 2007 года, после чего разработка проекта остановилось, а разработчики переключились на развитие mod_wsgi. Более того, в последние годы из-за ошибки в коде mod_python, данный модуль не мог функционировать совместно с последними версиями http-сервера Apache 2.2/2.4 без наложения дополнительных патчей, поддержкой которых занимались мантейнеры пакетов дистрибутивов. Кроме того, mod_python не совместим с Python 3 и желающих осуществить его портирование не нашлось.

Пользователям, которые продолжают использовать mod_python, рекомендуется рассмотреть вопрос о переходе на использование более производительного интерфейса WSGI, реализованного в модуле mod_wsgi. Модуль был mod_wsgi создан одним из разработчиков mod_python с целью решения проблем с производительностью и изолированием выполнения скриптов разных пользователей. Рекомендации по переработке специфичных для mod_python обработчиков запросов представлены в данной заметке. К счастью ситуации, требующие нетривиального вмешательства при миграции на mod_wsgi, встречаются достаточно редко, а все современные CMS и web-фреймворки, написанные на языке Python, поддерживают WSGI из коробки.

  1. Главная ссылка к новости (http://blog.dscpl.com.au/2010/...)
Автор новости: Konstantin P.
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/27087-pythpn
Ключевые слова: pythpn, apache, mpd_pythpn
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (58) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 13:35, 24/06/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Осталось для апача сделать нормальный модуль FastCGI под свободной лицензией, и mod_wsgi тоже можно зарывать.

    Впрочем, и апач скоро можно зарывать, легковесные серверы этот мотокомбайн потихоньку теснят.

     
     
  • 2.3, anonymous (??), 13:59, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вроде с точностью наоборот. Когда допилят mod_wsgi то это старье FastCGI нужно
    закапывать ...
     
     
  • 3.5, Аноним (-), 14:11, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    mod_wsgi работает только с питоном, и то не без проблем Т к встраивать интерп... большой текст свёрнут, показать
     
     
  • 4.7, anonymous (??), 14:28, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Т. к. встраивать интерпретатор не самого легковесного языка в в HTTP-сервер

    Те нужно выкинуть mod_php и заменить его на php-cgi ? ;)


     
     
  • 5.10, arcade (ok), 14:46, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ну лично я - уже. Заодно значительно разгрузил сервера.
     
     
  • 6.42, Dvorkin (ok), 10:58, 25/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Заодно значительно разгрузил сервера.

    от посетителей? :)

     
  • 5.11, Nas_tradamus (ok), 14:56, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >> Т. к. встраивать интерпретатор не самого легковесного языка в в HTTP-сервер
    >
    >Те нужно выкинуть mod_php и заменить его на php-cgi ? ;)

    Ни раз встречал статьи о развеивании мифов о том, что php-cgi якобы быстрее mod_php.

     
     
  • 6.16, Аноним (-), 15:44, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Ни раз встречал статьи о развеивании мифов о том, что php-cgi якобы
    >быстрее mod_php.

    Не путайте сам со себе php-cgi, работающий как обычный CGI-скрипт, с запуском PHP под управлением FastCGI.
    FastCGI достаточно простая и прозрачная технология, трудно придумать ситуацию, когда mod_php может оказаться быстрее. Но эта простота в FastCGI выливается иногда в значительный недостаток, делающим его уделом standalone-проектов и мешающим его использованию в системах с несколькими сайтами/пользователями или когда у проекта много разных скриптов. FastCGI не для массовых систем, а для отдельных крупных проектов.

     
     
  • 7.17, FractalizeR (ok), 15:52, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Но эта простота в FastCGI выливается иногда в значительный
    >недостаток, делающим его уделом standalone-проектов и мешающим его использованию в >системах с несколькими сайтами/пользователями или когда у проекта много разных скриптов. >FastCGI не для массовых систем, а для отдельных крупных проектов.

    php-fpm решает некоторые из этих проблем. Правда, в основном ценой снижения простоты.

     
  • 7.45, Аноним (45), 12:19, 25/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Что мешает использовать FactCGI для массовых систем?
     
     
  • 8.49, Имя123321 (?), 21:43, 25/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    разделение привелегий разных пользователей хостинга мешает для каждого пользо... текст свёрнут, показать
     
     
  • 9.53, User294 (ok), 22:52, 25/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Shared хостинги вообще строго говоря большие помойки, которые должны умереть Уж... текст свёрнут, показать
     
  • 9.61, redixin (?), 20:36, 28/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Вообщето php-cgi запускать на апаче через fastcgi это даже не смешно А вот и не... текст свёрнут, показать
     
  • 5.13, FractalizeR (ok), 15:19, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Совершенно верно. На php-fpm, если быть точным.
     
  • 4.12, dq0s4y71 (??), 15:05, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > mod_wsgi работает только с питоном, и то не без проблем. Т. к. встраивать интерпретатор не самого легковесного языка в в HTTP-сервер - то ещё решение. Это уже Windows-way какой-то.

    Хм. Интересно, а Перл - легковесный язык?

     
     
  • 5.25, Ярослав (??), 18:18, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А с чем вы сравниваете? В принципе, довольно легковесный. Возьму на себя смелость предположить, что легче Python-а и PHP.

    Главные затраты приходятся на запуск интерпретатора. Когда он уже загружен, программы на Perl интерпретируются очень быстро.

    Я думаю, именно это позволило встроить Perl в такие программы, как Exim и nginx. Отметим, что в nginx он по-умолчанию не ставится, что и понятно. Не во всех случаях возможности Perl нужны.

     
  • 4.26, аноним (?), 18:27, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >mod_wsgi работает только с питоном, и то не без проблем. Т. к.встраивать интерпретатор не самого легковесного языка в в HTTP-сервер - то ещё решение. Это уже Windows-way какой-то.

    А теперь покажи нам _ГДЕ_ же в коде mod_wsgi ты нашёл Python?!?!

    Ыксперты жгутЪ, ага ...

     
     
  • 5.28, FractalizeR (ok), 18:43, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>mod_wsgi работает только с питоном, и то не без проблем. Т. к.встраивать интерпретатор не самого легковесного языка в в HTTP-сервер - то ещё решение. Это уже Windows-way какой-то.
    >
    >А теперь покажи нам _ГДЕ_ же в коде mod_wsgi ты нашёл Python?!?!
    >
    >
    >Ыксперты жгутЪ, ага ...

    Похоже, тут: http://ru.wikipedia.org/wiki/Mod_wsgi http://ru.wikipedia.org/wiki/WSGI

     
     
  • 6.32, аноним (?), 20:17, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>>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.

    Ну и много другого интересного.

     
     
  • 7.33, Аноним (-), 20:27, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ты чудо, речь была о том, что mod_wsgi линкуется с питоньим рантаймом и запускает питоний интерпретатор прямо из апачевских процессов.
     
  • 7.35, индивид (?), 21:15, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Не читайте русскую вику, особенно если не понимаете русский.

    Не учите других, на каком языке читать, если не можете прочесть программный код.

    > 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 практически один в один, только на языке С.

    Вам только остается понять, как такое может быть. Вот для этого как раз и нужно знать языки программирования, а не только английский, знанием которого вы так гордитесь.

     
  • 5.29, User294 (ok), 18:45, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>mod_wsgi работает только с питоном, и то не без проблем. Т. к.встраивать интерпретатор не
    >самого легковесного языка в в HTTP-сервер - то ещё решение. Это уже Windows-way какой-то.
    >А теперь покажи нам _ГДЕ_ же в коде mod_wsgi ты нашёл Python?!?!

    Протокол WSGI - откровенно ориентирован на питон, если мне склероз не изменяет. И уж не этот ли протокол случайно Сысоев назвал удивительным по степени дебильности? Или его соседа, который не сильно от него отличается.

     
     
  • 6.30, Michael (??), 19:01, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    ага: https://www.opennet.ru/openforum/vsluhforumID3/67791.html#7
     
  • 6.31, аноним (?), 20:11, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>>встраивать интерпретатор не самого легковесного языка
    >>>в в HTTP-сервер - то ещё решение.
    >>А теперь покажи нам _ГДЕ_ же в коде mod_wsgi ты нашёл Python?!?!
    >Протокол WSGI - откровенно ориентирован на питон,

    Я с этим и не спорю. Вот только сам mod_wsgi написан на чистом таком С :)

    >если мне склероз не изменяет. И уж не этот ли протокол случайно
    >Сысоев назвал удивительным по степени дебильности?

    Не изменяет - его! И по делу.
    Но если честно - а много ли вообще не дебильных протоколов? :)
    Ну и самое главное - лучше уж дебильноватый, но стандарт, чем каждый свое "не имеющее аналогов" ...

     
     
  • 7.36, индивид (?), 21:29, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>Протокол WSGI - откровенно ориентирован на питон,
    >Я с этим и не спорю.

    Да уж, учитывая расплывчатось формулировки "ориентирован на питон", здесь как раз можно было и поспорить. Поскольку может ведь случиться так, что написано на Питоне, но на Питон не ориентировано. А может быть написано на С, а все равно получается "чистый такой Python".

    >Вот только сам mod_wsgi написан на чистом таком С :)

    Вот как раз и интересно, что такое в вашем понимании "чистый такой С". И какой С в вашем понимании может тогда быть не чистым.

    И самое главное, что по-вашему это меняет, если там "чистый такой С", но все равно "directly against the internal <...> Python application programming interfaces", как вы сами это процитировали выше.

    > Ну и самое главное - лучше уж дебильноватый, но стандарт, чем каждый свое "не имеющее аналогов" ...

    Может лучше, а может хуже. Только чтобы делать подобные заявления нужно в этом разбираться. А вы уровень своих познаний уже показали. Так что просто тыкаете пальцем в небо рассуждая, что лучше, а что хуже.

     
     
  • 8.39, Аноним (-), 00:02, 25/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Протокол WSGI - это название стандартного API Питона для взаимодействия с веб-... текст свёрнут, показать
     
     
  • 9.40, Ostrov (??), 10:09, 25/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Чей стандарт Питона Ну так пусть он его и мучает Вам надо еще и понятие слова... текст свёрнут, показать
     
  • 9.43, Dvorkin (ok), 11:05, 25/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    бабушка, у вас маразм уродливый питонский протокол - это питонская личная суксу... текст свёрнут, показать
     
  • 7.52, User294 (ok), 22:43, 25/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Я с этим и не спорю. Вот только сам mod_wsgi написан на
    >чистом таком С :)

    Питон тоже на C написан, IIRC. Но сями не является. Хоть и может юзать сишные либы как я понимаю.

    >Не изменяет - его! И по делу.

    :-)

    >Но если честно - а много ли вообще не дебильных протоколов? :)

    Честно? Немного. Весьма. Почему-то большая часть протоколов - именно дебильные (звучит почти как "все пи...сы", но ведь правда же! :D).

    >Ну и самое главное - лучше уж дебильноватый, но стандарт, чем каждый
    >свое "не имеющее аналогов" ...

    А еще лучше - не дебильноватый и стандарт. Я слишком многого хочу в этой жизни? Или стандарт по какому-то неведомому закону природы просто обязан быть дебильным и отстойным, чтобы кому-то зудело в нижней части спины сделать лучше? :)

     
  • 6.46, eyeland (?), 12:24, 25/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>>mod_wsgi работает только с питоном, и то не без проблем. Т. к.встраивать интерпретатор не
    >>самого легковесного языка в в HTTP-сервер - то ещё решение. Это уже Windows-way какой-то.
    >>А теперь покажи нам _ГДЕ_ же в коде mod_wsgi ты нашёл Python?!?!
    >
    >Протокол WSGI - откровенно ориентирован на питон, если мне склероз не изменяет.
    >И уж не этот ли протокол случайно Сысоев назвал удивительным по
    >степени дебильности? Или его соседа, который не сильно от него отличается.
    >

    WSGI Это не протокол. Удивительным по степени идиотизма он назвал uWSGI, но это резковато сказано.

     
  • 6.47, oxyum (ok), 17:46, 25/06/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Протокол WSGI - откровенно ориентирован на питон, если мне склероз не изменяет.

    Ровно в той же мере, что и CGI на PHP или Perl. Проще говоря этот протокол был разработан в Python community, но под Python он ни разу завязан. Просто 99% реализаций этого протокола написаны на Python. Но написать реализацию под например Perl вам ничто не мешает.

    >И уж не этот ли протокол случайно Сысоев назвал удивительным по
    >степени дебильности?

    Нет, не его. Ему не нравится uWSGI, который с протоколом WSGI имеет не очень многое. Собственно говоря модуль для nginx написан на основе модуля FastCGI. И к FastCGI/SCGI и другим подобным протоколам у Игоря примерно такие же претензии.

    > Или его соседа, который не сильно от него отличается.

    Отличается и ОЧЕНЬ сильно. Общее по сути только в названии.

     
     
  • 7.48, redixin (?), 17:51, 25/06/2010 [^] [^^] [^^^] [ответить]  
  • +/

    >Проще говоря этот протокол был разработан в Python community, но под
    >Python он ни разу завязан. Просто 99% реализаций этого протокола написаны
    >на Python. Но написать реализацию под например Perl вам ничто не
    >мешает.

    Ну елки зеленые.

    WSGI это не протокол, это стандарт взаимодействия python приложения с http сервером.

    python и только.

     

  • 1.2, Vaso_Petrovich (?), 13:43, 24/06/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Впрочем, и апач скоро можно зарывать, легковесные серверы этот мотокомбайн потихоньку теснят.

    Ври, ври, да не перевирай... Или же ссылки в студию.

     
     
  • 2.9, www2 (??), 14:31, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >Ври, ври, да не перевирай... Или же ссылки в студию.

    То, что сейчас можно найти по ссылкам, которых вы требуете - это инерция. Люди как научились ставить "опаче" и писать под него программы с использованием .htaccess и .htpasswd, так и продолжают. И именно эта инерция и мешает занять другим веб-серверам его место.


     
     
  • 3.14, Nas_tradamus (ok), 15:24, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>Ври, ври, да не перевирай... Или же ссылки в студию.
    >
    >То, что сейчас можно найти по ссылкам, которых вы требуете - это
    >инерция. Люди как научились ставить "опаче" и писать под него программы
    >с использованием .htaccess и .htpasswd, так и продолжают. И именно эта
    >инерция и мешает занять другим веб-серверам его место.

    Да еще и куча CMS с обязательной поддержкой Apache (читай ".htaccess").

     
  • 3.15, FractalizeR (ok), 15:29, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>Ври, ври, да не перевирай... Или же ссылки в студию.
    >
    >То, что сейчас можно найти по ссылкам, которых вы требуете - это
    >инерция. Люди как научились ставить "опаче" и писать под него программы
    >с использованием .htaccess и .htpasswd, так и продолжают. И именно эта
    >инерция и мешает занять другим веб-серверам его место.

    Люди научились писать... программы? Под apache? C использованием .htaccess???

    А есть какой-нибудь столь же стабильный, удобный и функциональный конкурент для Apache кстати?

     
     
  • 4.37, индивид (?), 21:40, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >А есть какой-нибудь столь же стабильный, удобный и функциональный конкурент для Apache кстати?

    Ну если конкретно для вас Apache - самый "стабильный, удобный и функциональный", то зачем других то по себе судить.

    Стабильность - смотря какой ценой она достигается. А Вы считаете, что Apache хотя бы по стабильности вне конкуренции? Ну ваше право так считать.

    Удобство - чисто субъективная характеристика.

    Функционал. Вы считате, что для разработчика важнее готовый "функционал", чем средства для создания функционала? Если так, то вы скорее не разработчик, а просто "продвинутый юзер", чуть более, чем собиратель юзер-интерфейсов "из кубиков".

     
  • 3.34, Michael Shigorin (ok), 20:47, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > И именно эта инерция и мешает занять другим веб-серверам его место.

    Ойданупрям.

    Апач -- это платформа, nginx -- это заточенный под сознательно более узкий круг задач сервер.  Разницу, думаю, сами понимаете.

     
     
  • 4.38, индивид (?), 21:51, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Ойданупрям.
    >
    >Апач -- это платформа, nginx -- это заточенный под сознательно более узкий круг задач сервер.  Разницу, думаю, сами понимаете.

    Когда не знают, что сказать, говорят "платформа".
    И что же по-вашему мешает быть какой-то "платформе" быть "сознательно заточенной" под более узкий круг задач?
    И что, с другой стороны, по-вашему в Апаче больше "платформенного", чем в других?

    А на самом деле, просто как все поклонники ширпотреба, вы путаете широту "круга задач" с количеством потребителей и популярностью.
    Хотя обычно зависимоть обратная. Чем больше потребителей, тем меньший "круг задач" они способны решать в виду шаблонности своего мышления и похожести друг на друга.

     
     
  • 5.50, Имя123321 (?), 22:17, 25/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >Когда не знают, что сказать, говорят "платформа".

    и ведь правда!

    (конешно щаз уйду в offtop, но немогу этого не добавить :))

    в русской документации (MSDN) по .NET -- слово "Framework" с англисского-на-русский везде перевели как "платформа".

    а всё потомучто переводчики не знали что ещё и в русском языке есть слово "програмный каркас"

     
  • 5.56, Michael Shigorin (ok), 11:55, 26/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>Апач -- это платформа
    >Когда не знают, что сказать, говорят "платформа".

    Ясно, не понимаете.  Попробую на пальцах.

    Платформа (когда слово применено по назначению) -- это не самоценность, а то, ценность чего обуславливается возможностью надстраиваться сверху.  Что железобетонная, что программная.

    >И что, с другой стороны, по-вашему в Апаче больше "платформенного", чем в
    >других?

    Он стал "домом" для множества сторонних разработчиков модулей, приносящих дополнительную функциональность итоговому продукту.  Назовите другой httpd с сопоставимым выбором модулей (или иначе -- доступной в пределе функциональности), чтоб не бегать за неопределёнными другими.  Я другого такого попросту не знаю, потому и интересуюсь.

    >И что же по-вашему мешает быть какой-то "платформе" быть "сознательно заточенной"
    >под более узкий круг задач?

    Ничто -- например, у апача рекордная производительность попросту сознательно не включена в задачи.

    >А на самом деле, просто как все поклонники ширпотреба, вы путаете широту
    >"круга задач" с количеством потребителей и популярностью.

    Глупенький, популярность свободных проектов (тем более не из модной эпохи) как раз и определялась применимостью и качеством. :)  Поразмышляйте над тем, как NCSA httpd стал "a patchy httpd", что ли.

    >Хотя обычно зависимоть обратная.

    Это среди вас, любителей как раз ширпотреба.

    PS: я до сих пор применяю и местами майнтейню apache-1.3 в альте, если что.

    PPS: "a patchy server", во, вспомнил.

     
     
  • 6.57, Аноним (-), 12:23, 26/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >я до сих пор применяю и местами майнтейню apache-1.3 в альте, если что.

    Надеюсь, всё у вас будет хорошо.

     
  • 6.58, индивид (?), 16:52, 26/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А ну с этой точки зрения конечно да Только в ИТ-мире в отличии от физического м... большой текст свёрнут, показать
     
     
  • 7.59, индивид (?), 17:02, 26/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >>Да уж конечно. Все поклонники ширпотреба убеждены, что их любимое самое качественное и применимое, ведь оно такое функциональное и сверхунастраивоемое.

    *сверхунаДстраивоемое*

     
     
  • 8.60, индивид (?), 04:44, 27/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    сверху-наДстраивАемое - видимо даже так ... текст свёрнут, показать
     
  • 7.62, Michael Shigorin (ok), 15:15, 06/08/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Пробовали Надо же, то есть термины вроде высокоуровневое API , низкоуровневый... большой текст свёрнут, показать
     
  • 4.54, User294 (ok), 22:58, 25/06/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >Апач -- это платформа,

    Апач пытается быть всем и сразу. В итоге работая не особо эффективно и давно уже просрав основную идею юниксвея по части делания одной вещи и хорошо. Да, делает уйму всего. И в итоге - стало оно энтерпрайзным софтом. Со всеми вытекающими - как то монструозный переросток с уймой ненужных 90% юзерам фич, которые требуют тем не менее покупать могучие сервера для того с чем справился бы и селерон у Васи под шкафом.

     
  • 2.18, аноним (?), 16:15, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Да netcraft хотя-бы. По-моему надо быть вообще не бум-бум в web технологиях чтобы не понимать очевидность этого процесса.
     

  • 1.4, mag (??), 14:06, 24/06/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    apache возможно сместят с front-end'a, но с обработкой кучи разных скриптов он пока неплохо справляется
     
     
  • 2.8, www2 (??), 14:28, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Apache - это нечто среднее между веб-сервером и сервером приложений. Являясь одновременно и тем и другим, он одновременно проигрывает и веб-серверам и серверам приложений.
     
     
  • 3.21, FractalizeR (ok), 16:29, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Apache - это нечто среднее между веб-сервером и сервером приложений. Являясь одновременно
    >и тем и другим, он одновременно проигрывает и веб-серверам и серверам
    >приложений.

    Чем Апач вам напоминает сервер приложений?

     
     
  • 4.27, User294 (ok), 18:40, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    mod_php и подобными, очевидно. А как фронтэнд и сервер статики он монструозен и неповоротлив. Достаточно посмотреть что втыкают реально нагруженные проекты для этих целей.
     

  • 1.19, Rodegast (??), 16:20, 24/06/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Джангокапец?
     
     
  • 2.20, koblin (ok), 16:24, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    django работает с wsgi
     
     
  • 3.22, spanasik (ok), 16:49, 24/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    да он и с FastCGI работает, как ни странно :-)
     
     
  • 4.55, Имя123321 (?), 23:05, 25/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    ну.... если сайт работает на WSGI, то ясное дело что он же работает: и с FastCGI, и с SCGI, и с CGI, ... и  фиг ещё знает с чем :-)
     

  • 1.23, Аноним (-), 17:07, 24/06/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    А мне кажется, для WSGI просто выбрали неудачное название, потому все и его и ставят на одну полку с протоколами CGI и FastCGI. Хотя все три - совсем разные вещи, в одном случае интерфейс на уровне Питона, в другом - на уровне UNIX-like  модели исполнения программ, а в третьем случае - вообще сокеты.

    Лучше бы назвали его Python Web API, по аналогии с Python DB API, и всё бы встало на свои места.

     
     
  • 2.51, Имя123321 (?), 22:24, 25/06/2010 [^] [^^] [^^^] [ответить]  
  • +/
    на самом деле -- думаю что только совсем малю людей путаются..

    ...другие же вполне понимают что WSGI+SCGI вполне нормлаьный стэк :-)

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру