On Monday 10 August 2009 19:57:53 Timo Sirainen wrote:
I'm trying to figure out how exactly v2.0 should be parsing configuration files. The most annoying part is if it should always just "use whatever comes first in config" or try some kind of a "use most specific rule".
I generally prefer the "most specific rule wins". If that is not the case, it should not be possible to specify the same configuration within containers of different scope. It is not intuitive to have a value in a restricted scope and in a more general scope, and there are situations when the general value is used even though the specifiv scope
The "most specific" kind of makes more sense initially, but then you start wondering how to handle e.g.:
- User logs in to imap from 192.168.0.1. What is foo's value?
protocol imap { remote_ip 192.168.0.0/16 { foo = foo } } remote_ip 192.168.0.0/24 { foo = bar }
This one is easy. It should be foo in any case :-)
Protocol sections that are more specific are an existing and coarse-granular concept, and AFAIk now it doesn't matter whether the protocol section is before or after the general setting. This concept should in any case be retained.
- User logs in from 192.168.0.1 to 10.1.2.3. What is foo's value?
local_ip 192.168.0.1 { remote_ip 10.1.2.0/24 { foo = foo } } remote_ip 10.1.2.3 { local_ip 192.168.0.0/24 { foo = bar } }
Any thoughts?
Perhaps this should be invalid.
Rainer