Re: use

["Pavel V." <pavel2000@xxxxxx>]

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

Вы писали 11 июля 2011 г., 21:56:49:

> On 11.07.2011 17:12, Pavel V. wrote:

>> Желание / видение -  навеяное модулем mod_macro - это не то, что
>> обсуждается в треде. Если кто-то понимает это именно как mod_macro -
>> это не верно :-)

> http://www.cri.ensmp.fr/~coelho/mod_macro/

> - там есть достаточно интересные идеи, которые можно применить в nginx,
> только вместо html-like синтаксиса httpd использовать C-like синтаксис.

>> Хотелось бы иметь возможность описывать и использовать некий блок
>> директив конфигурации, _НО_: область видимости/применимости блока - server 
>> {}.

> почему такое ограничение - только внутри блока server?

Целенаправленное ограничение, чтобы описание блока директив было
"недалеко" от использования. Для прочего - использовать include.

Это предложение/ограничение также развивает ваше:

>2. если есть несколько сотен сайтов, то вполне логичным будет
>делать 1 сайт == 1 конфигурационный файл. использование include
>увеличивает количество конфигурационных файлов в несколько раз.

А также вопрос области применимости:

>следовательно - нельзя будет понять, изменения в этом файле
>затронут только один/несколько сайтов, или изменения в этом
>файле (например,  fastcgi_params) затронут многие сайты.

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

но "чуть-чуть по-другому", не вводя лишней области видимости "текущий
файл".

Думаю, наличие дополнительной функции в виде директивы block,
доступной для объявления в любом месте конфига,  директивы use,
доступной для использования в любом месте, ниже чем директива block,
а также правила переопределения директив "директива, описанная ниже по конфигу
имеет более высокий приоритет", могло бы несколько изменить подход к
написанию конфигов (это было бы нечто, подобное конфигурированию
nagios).

Хотел было привести пример конфига, но пока фантазировал, реально
извратил его вложенностями и перекрытиями.
Думаю, что вовремя остановился :-)

Тут-то и возникает вопрос - всем ли действительно нужен perl-like подход
"есть много путей сделать это" при конфигурировании nginx, насколько
сильно вздрогнет рассылка решая головоломки "откуда какая директива сработала".

В случае глобального применения такого "блока", но без поддержки
параметров - особого смысла в директивах block/use вроде и  нет, можно
обходиться include. Когда внутри одного server {} требуется несколько групп 
почти
одинаковых директив, то выносить одну-две директивы в отдельный файл
для include - это неудобно и "увеличивает количество конфигурационных
файлов в несколько раз". На данный момент - приходится их
копировать из location в location.

C наличием директив block/use было бы удобнее, и /для моих задач/
достаточно возможности описывать блоки ровно внутри server{}. 


> тогда уж лучше реализовывать более общую директиву macro/use,
> с параметрами, как это сделано в апачевском модуле mod_macro.

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


Да, пожалуй. В принципе, впоследствии, ограниченная директива block {}
может выродиться в mod_macro, по синтаксису

block backend_A ($varA, $varB) {
   ...
   block_backend_A_directives_that_uses_VARS;
   ...
}

location / {
          use backend_A $someVarForA 10;
}

И тогда подобного рода ( только внутри server {} )
ограничение применимости станет слишком сильным
ограничением.



-- 
С уважением,
 Pavel                          mailto:pavel2000@xxxxxx


_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru