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". The "most specific" kind of makes more sense initially,
but then you start wondering how to handle e.g.:
1) 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
}
2) 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?
I think the easiest scheme to keep in my brain would be to evaluate the
blocks, in order, as if they were branches in code. Fooling around with
an arbitrary order of evaluation/specificity would be a recipe for
disaster (see, for example, any CSS engine).
So, something like,
protocol imap {
remote_ip 192.168.0.0/16 {
foo = foo
}
}
would translate to,
if (protocol == imap) {
if (remote_ip matches 192.168.0.0/16) {
foo = foo
}
}
and then later,
remote_ip 192.168.0.0/24 {
foo = bar
}
would set the value of 'foo' to 'bar', since it would evaluate in a
similar fashion, and comes later in the config file.
It's easy to explain, easy to implement, and easy to debug. Ultimately,
the users are going to have to understand how it works in order to
configure Dovecot properly. "Put the most general rules first, and then
override them" is a practice with which most of us are already familiar.
