[Dovecot] v2.0 configuration parsing

[Matthijs Kooijman]

> You are right, and I left out half of my thoughts. I think there should be 
> only a coarse grained concept of "more specific rules" - e.g. a protocol 
> section is more specific than general config, and a local or remote IP 
> restriction is more specific than a protocol section. I think that the values 
> of these context selectors should not define "more specific". Within one of 
> these levels, either conflicting settings should be invalid, 
But that would prevent the following (intuitive) config from working:

  remote_ip 192.168.0.0/16 {
    foo = bar
  }

  remote_ip 192.168.10.0/24 {
    foo = baz
  }

This would need some kind of condition like
  
  remote_ip 192.168.0.0/16 && !192.168.10.0/24 {..}

or something.

> or maybe better yet, a "last wins" rule should apply.
Or you would indeed use this, which makes the above config easy to write
wrongly. (If you swap the conditions). You might still detect that a later
directive completely overrides a previous setting in all cases and issue a
warning, but this is probably hard to do in general.

An alternative that just occured to me is to always do these kind of
"exceptions" in a nested way. The above would then become:

  remote_ip 192.168.0.0/16 {
    foo = bar

    remote_ip 192.168.10.0/24 {
      foo = baz
    }
  }

which is probably even more intuitive than my first example. This way, the
user explicitly specifies which directives can override other directives. This
is comparable to having a fixed order of "protocol", "remote_ip", "local_ip"
that was proposed somewhere in this thread, but allows the user to pick the
order.

This does mean that you might need explicit "else", or "other" clauses, since
you cannot mix different selectors on the same level of the hierarchy.

protocol imap {
  remote_ip 192.168.0.0/24 {
    foo = bar
  }
}
protocol other 
  remote_ip = 192.168.10.0/16 {
    foo = baz
  }
}

A big downside of this approach is probably that you can't easily add a rule
for some remote_ip condition regardless of the protocol to the last example,
since that should then be specified in both protocol blocks... So, not sure if
this is really a useful suggestion, but perhaps thinking about it will help
:-)

Gr.

Matthijs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://dovecot.org/pipermail/dovecot/attachments/20090811/b93dda83/attachment.bin