ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Ужосы какие-то пишут про nginx



Здравствуйте, Denis.

Вы писали 18 апреля 2008 г., 16:07:05:

>>Я не против документирования. Я не хочу это делать сам, поскольку
>>не хочу делать одно и то же несколько раз - интерфейсы меняются.

> Проблема даже не в документировании, а в обеспечении полной совместимости
> между версиями путем фиксации базовых интерфесов, чтобы человек, который
> смог разобраться с версией 0.5, не тратил время на поиск аналогов предыдущих
> интерфесов в версии 0.6. Даже если я успел документировать версию 0.5,
> в 0.* она уже бесполезна. Есть примеры, когда кто-то писал свой upstream
> модуль для старой версии nginx, который уже не работал в следующей.

о такой проблеме написано в самом начале сайта http://sysoev.ru/nginx/
поэтому разработчику стороннего модуля выбор остается не очень большой:
или постоянно переделывать свой модуль для поддержки новых версий nginx,
или сделать нужную функциональность средствами встроенного mod_perl,
или внешнего fastcgi-сервера. обычно это можно сделать почти всегда.

если этот модуль действительно нужен всем/большинству пользователей
nginx, можно попробовать включить его код в основной дистрибутив nginx?

> Итого, нужен фиксированный документированный "стандарт" интерфесов для
> nginx, который не меняется. Например, можно адаптировать Apache DSO и apxs.

если нужен фиксированный стандарт на "kernel api",
что в таком случае мешает писать модули для Apache,
а nginx использовать только в качестве http-акселератора ?

кроме стабильного API в этом случае будет также получена
и запрашиваемая "частичная потеря производительности".

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

такой модульный веб-сервер уже есть, называется lighttpd.
только там ~ в каждой версии находится "few security bugs".
качество кода nginx в этом плане намного лучше, чем у lighttpd.

PS может быть не стоит превращать nginx в lighttpd или apache ?

-- 
С уважением,
 Gena                          mailto:gmm@xxxxxxxxx




 




Copyright © Lexa Software, 1996-2009.