[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: back-meta does not compile (ITS#2483)
I missed the posting on the bugs mailing list. I agree with most of your
comments.
Once I ensure that the current implementation compiles and works properly,
I will discuss the issues below on the developer mailing list before
changing the implementation.
-Apurva
----- Forwarded by Apurva Kumar/India/IBM on 05/15/03 10:45 AM -----
"Howard Chu"
<hyc@highlandsun.com> To: <openldap-devel@OpenLDAP.org>
Sent by: cc:
owner-openldap-devel@O Subject: RE: back-meta does not compile (ITS#2483)
penLDAP.org
05/14/03 06:17 PM
> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of ando@sys-net.it
> As far as I can tell, the LDAP_CACHING code suffers
> from an unnecessary overimplementation, since I don't
> see the need to split caches on different local
> databases. I think caching should have been kept
> as separate as possible from the actual storage,
> using callbacks to invoke the more appropriate
> storage. In fact, now caching relies on back-ldbm,
> while an upgrade to back-bdb would be better, since
> we might decide to get rid of back-ldbm at some point.
Yes, I still have some issues with the current code. As I noted in a
previous
post, the flag indicating "this is a cache" should be an attribute of the
actual database, not a flag in the Operation. If the cache code's sparse
DIT
usage were changed slightly, we wouldn't even need special treatment in the
backend.
> We may also decide to get rid of back-meta itself,
> to glue together multiple instances of back-ldap.
I expect to have a framework for configuring stacked modules checked in
Real
Soon Now. I haven't done a full audit yet of what other features in
back-meta
need to be migrated into a new module if we get rid of back-meta. So far
all
I know is we want the rewrite engine to be usable with other backends, and
we
need a mechanism to allow multithreaded, asynchronous searching of
subordinate backends.
The latter can be done with not much work, simply submitting new Operations
into the thread pool for each subordinate search. We can add an optional
argument to the "subordinate" keyword, e.g. "async" to tell back-glue to
search a particular backend asynchronously.
> I think we should move the caching code, which is
> itself a nice piece of software, into a separate layer,
> and make it call arbitrary storages at well defined
> entry points.
Yes...
Currently the code uses a special flag that allows it to perform some
privileged operations, such as creating entries whose parent does not
exist,
creating sparse entries without schema checking, bypassing search limits,
and
bypassing access controls on its operations. Rolling all of these features
into a single flag is unnecessary in some areas and just inflexible
otherwise.
For the latter two conditions, all that's needed is to set the operation's
DN
to the backend's rootDN when calling the backend.
For bypassing the schema checking, we should have simply added a new
backend
flag SLAP_BFLAG_NO_SCHEMACHECKING; there may be other situations where
we'll
want this functionality and it shouldn't be specifically tied into this
cache
code.
For the sparse DIT, the current approach requires that each database
backend
be modified to allow this usage. It would probably be better if the cache
simply created stub entries for the missing parents, then it would be
usable
with any of the database backends without further modification.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support