Re: back-ldap and rewrite/remap in 2.3

["Pierangelo Masarati" <ando@sys-net.it>]

> Since making back-ldap slimmer/cleaner should also make it easier to fix
> if any problems do crop up, I think that's best.

OK, I'll give it a spin and commit ASAP.

>
> On the topic of backglue - does it really provide enough functionality
> for the purpose?

No.  Essentially, there are two limitations:

1) dealing with overlapping naming contexts is not possible;

2) the possibility to concurrently operate on the glued databases (e.g.
searches spanning the whole glued tree), which may be desirable when
glueing (slow) targets on slow connections, is not available.

I think (2) can still be obtained by allowing backglue to use more than
one thread, at the cost of carefully protecting/duplicating data shared
among threads.

I have no idea for (1) at the moment, apart from hacking backglue to
behave as back-meta does in these circumstances.

Of course, we can leave back-meta in place as long as it causes no harm,
to deal with those special cases.

> There's one area it is still definitely lacking; if a
> subordinate database is unreachable (e.g., it's a back-ldap that isn't
> currently answering) we have no way to report this in the search
> results. The LDAP_PARTIAL_RESULTS error code would have been useful here
> but that was deleted from LDAPv3. The best approach (hack) I've come up
> with so far is for backglue to return a Reference for any subtrees that
> return Unavailable, and let the client deal with the problem that way.

Sounds fine to me.

Ciao, p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497