Viktor Dukhovni:
> In postmast(1) there was no ambiguity between "." in a service name
> and "." between the service name and the service type, because
> these were specified separately "postmast [-s <service>] [-t <type>]
> ...". While integrating a super-set of postmast(1) functionality into
> postconf(1) Wietse has switched from "." to "/", but this may not
> solve the problem because some service names have "/" in them
> (paths of sockets outside /var/spool/postfix/{private,public}).
First, there is no ambiguity with service/type/parametername, because
there is no '/' in master.cf service names (on the other hand there
IS ambiguity with service.type.parametername, because '.' can appear
in service and parameter names).
There is no '/' in master.cf service names because master.cf services
must have sockets or FIFOs under the postfix-owned "private" or
"public" directory. It's unsafe for the Postfix master daemon to
open sockets or FIFOs in directories that aren't under control by
Postfix.
Second, the idea is to uniformly represent all configuration features
as "name = value" pairs, and to have the same uniform representation
in query results and in update requests.
The purpose of this is not to make the postconf command easier to
implement. Instead, the purpose is to make Postfix easier to manage
with third-party automated system management tools (whether open
source or closed). For that it is essential that all configuration
features can be represented in a uniform manner and that we avoid
the need to represent feature names as a combination of command-line
options and other command arguments (this could be an argument to
eliminate the -F/-P and to encode that into the feature name iself).
If all feature of Postfix can be represented as a list of name=value
pairs, for example:
feature context | name = value
====================|=====================
main.cf | parameter = value
master.cf field | service/type/field = value
master.cf -o override | service/type/parameter = value
and if this form can be used for both query resault and update
requests, then other systems can reason about Postfix and manage
settings in a less ad-hoc and hopefully more intelligent manner.
Wietse
