On 23.07.2011 21:12, António P. P. Almeida wrote:

>>>> Igor, likely nginx now need something like httpd mod_macro
>>>> to eliminate multiple duplicates of small config fragments
>>
>>> I followed the discussion on the russian ML. Yes something like
>>> your use suggestion would be great.
>>
>> that my message in russian ML:
>> http://www.lexa.ru/nginx-ru/msg41221.html
>>
>> in that proposal I make one mistake: "local" site config files also
>> includes in main nginx.conf config via include directive, for
>> example
>>
>> include /etc/nginx/virtual/*.conf;
>>
>> and all blocks will have global scope after this include in
>> nginx.conf now I can see only three solutions:
>>
>> 1. make two include-like directives, for example, 'include'
>> and 'require' - one inherit blocks/macros from included files
>> and one - not inherit.
>
> Bear in mind that I've just browsed some begginer docs on Nginx
> internals. But wouldn't that make the all process of merging the
> configurations when inheriting handlers too complex?

require is just the same directive as include, with one exception -
require ignores all macro definitions during process of "including".
this is not too complex for implementation in nginx.

[...]

>> also httpd mod_macro is feature-rich - it have macro arguments.
>> same feature can be implemented also for nginx. for example:
>>
>> define macro_name {...} - macro without arguments
>>
>> define macro_name( ARG1, ARG2, ARG3, ... ) {...} - macro with
>> arguments
>>
>> 'define' - new nginx keyword instead of 'block' (as in original
>> message) this is something like well known C-preprocessor #define
>> directive. because nginx have C-like syntax, not html-like, as
>> apache one.
>
> I would be happy with a "simple" define or defmacro that uses C like
> syntax. I prefer defmacro just to distinguish it from the C
> preprocessor directive. It avoids hypothetical confusions between C
> source and Nginx configuration.

I think this is bad idea. because nginx already use 'include'
directive, which looks like C preprocessor #include directive.
also if new nginx directive will be named 'define' - no problems.
new nginx directive 'define' and C preprocessor directive '#define'
distinguish one from another very well. same as 'include' and '#include'

> defmacro static_images {
> ## For static images don't log 404s and make the expire be maximal.
> expires max;
> log_not_found off;
> }
...
> location ^~ /other/img/ {
> static_images;
> }

and what happen with your configs if in future Igor implement in nginx
new first-class directive static_images ? may be better define + use ?

define static_images {
## For static images don't log 404s and make the expire be maximal.
expires max;
log_not_found off;
}

location ^~ /other/img/ {
use static_images;
}

also - 'defmacro' - this is not C-like syntax.

because textwihoutspaceshasverybadreadability.

C-like synxax is text_with_underscopes_instead_of_spaces;

> The scope could continue to be global and thus it wouldn't touch on
> the location configuration merge process and preserve all the current
> capabilities of hooking into the multitude of aspects of nginx
> processing cycle when writing a module.

this is dangerous.

if in one local site config file you write

define static_images { ... }

and in other local site config file by mistake you write

define static_inages { ... }

- nginx will sliently use static_images from prevous local site
config file and sliently ignone all your changes in current file.

this is bad approach.

this is break rule "Errors should never pass silently".

I think better - add one more 'require' directive with
fail-safe behaviour - and make all errors are not silent.

also look full list:

# python -c "import this"

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

I think these ideas also good for nginx config synax.

> Your proposal is great, but in the meantime a stopgap solution like
> the above would be great. Potentially it can make the configurations
> shorter, less prone to errors, and above all: avoid repetition.

and what about backward compatibility ?

if one feature or behaviour is implemented in nginx 1.x
- it can't newer be removed or changed before 2.0 release.
and... nginx 1.0 was released after 6 years of development.

--
Best regards,
Gena

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