[Date Prev][Date Next]
back-meta: phase I
This is only to start the debate.
The work I'm going to submit (could be next weekend) is basically made
of three parts. At this point they're all needed simultaneously, otherwise
something is going to break. So it may be accepted (in HEAD) as a whole,
or a new branch may be created. I think this is a decision I cannot take
on my own.
Let me describe in few words the blocks.
1) The dn (and more) rewrite stuff.
it is a library that is somehow not related to ldap.
I put it in libraries/librewrite. It is surely needed by
back-meta, and I applied it also to back-ldap as an
enhancement. It comes with its own include/rewrite.h
and simply requires the Makefile.in processing in configure.in
2) The back-ldap enhancements.
- rewrite, as told before. This is not strictly required,
but I found it useful.
- to increase the versatility of back-meta I moved Mark's
attribute/objectclass mapping on a per remote host basis.
I reused his code nearly untouched; however I had to change
the arguments of the functions. These changes (very limited)
apply also to back-ldap, to share most of the code.
- some minor fixes, which should be reviewed as well
by someone who's directly involved in back-ldap, unless
you really trust me :)
3) The back-meta stuff.
well, it's yet another backend. An entire new directory,
a --enable-meta configure directive (which requires
--enable-ldap to be set, so that many functions can be
shared). All the functionalities have been implemented,
many details need to be tuned. The best way to have
these things fixed would be to have someone try to
use it. I still need to thoroughly test the remapping
stuff, and I have to write some documentation.
BTW: we're using the enhanced back-ldap in production environment;
IMHO it can be considered rather stable. Today I deployed a back-meta
for testng in our architecture. It points a w2k AD, a Lotus Notes and
a OpenLDAP 2.0 slapd with back-ldbm and back-ldap databases, which
are all seen as one single DIT. Cool.
One final note: back-meta sounds a bit ambitious. It has little
to do with stuff like iPlanet's metadirectory. We have long term plans
to go in that direction, although we're not even sure we actually need
anything like that. Any suggestions for a different name are welcome.