Thanks Quanah for the answer. Sounds good. Regards, Kai
-----Original Message----- From: Quanah Gibson-Mount [mailto:[email protected]] Sent: Tuesday, January 26, 2016 1:53 PM To: Apache Directory Developers List <[email protected]> Subject: RE: JdbmPartition repair Yes. It's BSD license. <https://en.wikipedia.org/wiki/OpenLDAP> --Quanah --On Tuesday, January 26, 2016 5:35 AM +0000 "Zheng, Kai" <[email protected]> wrote: >>> If we are to do that one day, we would rather use LMDB, which is way >>> faster than SqlLite, proven, and small. > > Agree. Looking at the benchmark result > http://symas.com/mdb/microbench/, LMDB seems pretty good as well as > LevelDB. One question, is it license (the OpenLDAP public license) compatible > with ASF 2.0? > > Regards, > Kai > > -----Original Message----- > From: Emmanuel Lécharny [mailto:[email protected]] > Sent: Monday, January 25, 2016 11:58 PM > To: Apache Directory Developers List <[email protected]> > Subject: Re: JdbmPartition repair > > Le 25/01/16 15:27, Zheng, Kai a écrit : >> Thanks a lot for the detailed and insightful explanation. I'm not >> able to absorb it well because not familiar with the codes. It will >> serve as very good materials when someday I need to look into the LDAP >> things. >> The details make me believe it's very necessary to have a strong, >> mature, industry proven backend for the LDAP server because the LDAP >> things are already kinds of complex enough. We can't combine the LDAP >> logic with the storage engine, they need to be separated, developed >> and tested separately. Looks like Mavibot is going in this way and >> sounds good to me. What concerned me is that as we're lacking enough >> resources on developing it, it may still take some time to become >> mature and robust. > Mavibot code base is small : 17 947 SLOCS > > >> But if we leverage some existing engine, then we can focus on the >> LDAP stuffs and work on some advanced features, move on a little >> faster and have releases like 2.x, 3.x and so on. Sqlite yes is C, >> but it's supported on many platforms and Java can use it via JNI; > That would be a real pain. Linking som JNDI lib and make it a package > is really something we would like to avoid like plague. > > If we are to do that one day, we would rather use LMDB, which is way > faster than SqlLite, proven, and small. > >> it's a library, can be embedded in an application. You may dislike >> JNI, but only a few of APIs are going to be wrapped for the usage, >> and actually there're already wonderful wrappers for Java. Like >> SnappyJava, the JNI layer along with the library can be bundled >> within a jar file and get distributed exactly as a maven module. One >> thing I'm not sure is how well the LDAP entries fit with the sql >> table model, > Bottom line : very badly. Actually, using a SQL backend to store LDAP > element is probably the worst possible solution. Simply because LDAP > support multi-valued entries, something SAL databases don't support > antively. > >> but I guess there could be pretty much investigations in this direction. >> The benefit would be, saving us amounts of developing and debugging >> time, robust and high performance, transaction support and easy query. >> Some thoughts in case any helps. Thanks. > > Thanks. We have been evaluation all thos options for more than a > decade now :-) OpenLDAP has gone the exact same path, for the exact same > reasons. > > -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
