[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: should one single search be able to encompass several databases?
Stig Venaas wrote:
> On Thu, Jul 19, 2001 at 03:53:03PM +0200, Pierangelo Masarati wrote:
> > of course you can't, because if the backend with suffix "dc=test,dc=com"
> > comes first, you'll never be able to access the one with suffix
> > "dc=hr,dc=test,dc=com", and if the latter comes first you'll be able
> > to access it only if you come in straight with a search base
> > of "dc=hr,dc=test,dc=com" or higher. One clean (from the client's side,
> > but a bit involved from the server side) chance to get what you're
> > looking for is with a back-meta that proxies the two backends.
>
> I know it works that way, my question was more or less whether that is
> the behaviour we want. Does any spec say anything about this? The
> obvious thing today is of course to put it all in one database or use
> a referral.
I remember Kurt answering someone that meta- stuff is not in any spec,
and is likely not to be for long time, as it goes against the referral idea,
which is key to LDAP (not sure if I'm reporting Kurt's thoughts correctly :)
So meta- stuff is kinda implementor-dependent; if you read some
white-paper (commercial/ad stuff, mainly, e.g. from MicroSoft) you see
that meta- is a sort of a means to glue things together while migrating
towards a true LDAP system. This is how I intended it, and basically the
reason we needed something like that in OpenLDAP: to ease a big merge
between one of our customers and another big group, who wanted their
legacy stuff to be able to keep on working, while presenting the same info
in an unified manner for newly developed intranet applications.
Maybe we can try to get some spec out of it. I think it may get something
out of LDUP/LCUP as well, to allow some caching at the meta- engine
side. A future development would be a sort of join concept, which IMO
should be a set of rules to glue a subset of the attribs together in the
resulting entry based on some generalized key concept. This operation
looks very expensive, so it should be cached and driven by an asynchronous
join engine (a connector). Here the LCUP part comes into play.
Ando.
--
Dr. Pierangelo Masarati | voice: +39 02 2399 8309
Dip. Ing. Aerospaziale | fax: +39 02 2399 8334
Politecnico di Milano | mailto:masarati@aero.polimi.it
via La Masa 34, 20156 Milano, Italy | http://www.aero.polimi.it/~masarati