From: (no name) (no email)
Date: Mon Dec 01 2003 - 13:25:13 EST
On Mon, 1 Dec 2003, Liviu Daia wrote:
> My initial motivation for this was related to enhancing the
> behaviour of LDAP maps, but this mechanism could be interesting in
> general. Aside from the obvious uses as "pipes", map chains would be a
> clean solution for operations such as input or output quoting (thing RFC
> 2253 for LDAP, and SQL quoting), and result validation.
Quoting is a complex issue, because for multi-valued lookups it may be
too late to quote the result elements (when unquoted elements contain the
"," element delimiter). This said, filtering and other post-processing
will likel be useful in a variety of contexts.
> I suggest the syntax
>
> chain:/path/to/file
>
> where "/path/to/file" would be a plain file containing a list of maps.
> This would allow map chains to be used just like other maps.
This does solve the problem of how to include chains in access maps
without changing the restriction parser. On the other hand some users
prefer to put as much of the configuration as possible into main.cf. One
could (somewhat along the lines of the backwards compatibility hooks in
the snapshot LDAP driver) also support chain:parameter_prefix, or even a
more complex fully inlined form chain:{multi line data} which requires
parser changes.
> From the point of view of implementation, the only complication
> is related to handling intermediate multiple results, more precisely
> parsing them from the output of the plain maps. Obviously, this makes
> sense for the maps that return lists of addresses, but not otherwise.
Yes, the interpretation of results with embedded commas needs to be
configurable on a per chain or even map within chain basis.
> And whether a map is supposed to return address lists depends only on
> the context in which the map is used, not on the map itself. So far,
> the best way I can think of to handle this would be to add a flag to the
> individual maps in "/path/to/file", instructing the chain to split the
> result into multiple addresses at that point.
>
This seems reasonable. The chain map should come with a few in-line
filters. It might even be reasonable to use printf-like templates for
simple in-line filters which take data from the *original* input key
and/or the output of the previous map (current input key).
This would subsume some of the functionality of the LDAP changes proposed
by Diego Rivera. Some of the LDAP specific issues will not go away, unless
the LDAP maptype is augmented with an "ldapuri" maptype that can map an
input URI (base, scope, filter) and an input key to a result set. One
would also need to be able to specify RFC225[34] quoting of dynamic parts
of the URI.
The "dumbing down" of LDAP after chains are implemented is not an
immediate requirement, but is a reasonable design goal, because then the
LDAP maptype will be less "special" with the bells and whistles provided
by the chaining layer.
The key question I think, is whether the more general framework will be
understood by the users! Perhaps the current set of "just-right" if ad-hoc
mechanisms has more to offer in its simplicity than a more general
approach will have to offer in its flexibility. I don't think that as a
mathematician by training I am qualified to answer this question, I find
abstract systems *easier* to understand :-)
-- Viktor.
|
|
|