Re: syncrepl suffixmassage

[masarati@aero.polimi.it]

> We've talked about this before; it would be nice for the consumer to be
> able
> to pull updates from a different suffix on the provider than the one in
> use on
> the consumer. Just attaching the rwm overlay is not straightforward, since
> that expects to sit on a database and the consumer's queries are sent
> through
> direct LDAP calls. A potential kludge for this would be to rewrite all of
> the
> consumer client code in terms of backend calls through a back-ldap
> instance.
> That seems a little heavy-handed though.
>
> Another possibility may be to just expose some of the rwm overlay's entry
> points so the consumer can call them explicitly, faking enough of the
> context
> so we can call suffixmassage config. Suggestions?

Considering to limit ourselves to suffix massaging (no attribute mapping,
but DN-valued attribute massaging) we could operate at the entry level,
since the client either operates on entryUUIDs or turns messages into
entries before operating on them.  In this case, an entry_massage() call
that either no-ops or massages DNs would minimize the impact.

p.