Re: New Proxy cache overlay

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

One of the problems I see with both of these approaches
is that they don't say which if of the layers applied to
the source backend are applied before tee'ing to the
relay/rewrite backend.

Maybe we need something like:

database bdb
overlay post
overlay relay "o=example,c=us"
overlay pre
suffix "dc=example,dc=dc=com"
...

database relay
overlay rewrite
suffix "o=example,o=com"

The DN "o=example,c=us" basically names the pipe.

(Note that slapd.conf(5) should support these backends being
presented in either order.)

Kurt


At 05:30 AM 12/6/2003, Pierangelo Masarati wrote:
>Howard Chu wrote:
>
>>>-----Original Message-----
>>>From: owner-openldap-devel@OpenLDAP.org
>>>[mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Pierangelo Masarati
>>>   
>>
>> 
>>
>>>my DN rewrite/ attr mapping overlay is finally working.
>>>I could commit it very quickly (although not finished yet),
>>>but there are a couple of side effects:
>>>   
>>
>>I've been thinking that it might make sense to have a rewrite backend. An
>>overlay will modify an existing backend's behavior, so that the original
>>behavior isn't available. This is probably OK for back-ldap/back-meta that
>>are intended to integrate a foreign DIT into a local one. But there's also a
>>desire to provide alternate views into a local DIT, and this is where a
>>rewrite backend is more useful:
>>
>>database bdb
>>suffix dc=example,dc=com
>>
>>database rewrite
>>suffix o=example.com,c=us
>>target dc=example,dc=com
>><various mapping stuff>
>>
>>The idea here is that the rewrite backend will accept queries for its own
>>suffix, and map them to some other backend. This would be the equivalent of
>>the old suffixalias functionality, plus the rest of the mapping capabilities.
>>The original tree with its unmapped attributes is still directly accessible.
>>We can do this right now using back-ldap, but a rewrite backend could just
>>call the target backend internally.
>
>Sounds good.
>
>In my view this could be a sort of "transparent" backend,
>which relays another backend internally, and the rewrite/map
>layer is provided by the overlay.
>
># trivial case (nonsense: never invoked)
>database bdb
>suffix dc=example,dc=com
>
>database relay
>suffix dc=example,dc=com
>target dc=example,dc=com
>
># rewrite case
>database bdb
>suffix dc=example,dc=com
>
>database relay
>suffix o=example.com,c=us
>overlay rewrite-remap
>suffixmassage o=example.com,c=us dc=example,dc=com
>
>Relaying would be nearly costless.
>
>This allows to have the rewrite stuff finally in just one place,
>and add it also to other backends.  I'm mainly concerned with
>back-ldap and scripting backends.
>
>In this sense, it could be useful to separate DN rewriting from
>attribute mapping, at the cost of requiring two overlays.
>
>Ando.
>
>
>
>+----------------------------------------------------------------------------+
>|   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax:+390382476497    |
>+----------------------------------------------------------------------------+