directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quanah Gibson-Mount <qua...@zimbra.com>
Subject RE: JdbmPartition repair
Date Tue, 26 Jan 2016 05:53:19 GMT
Yes.  It's BSD license.

<https://en.wikipedia.org/wiki/OpenLDAP>

--Quanah

--On Tuesday, January 26, 2016 5:35 AM +0000 "Zheng, Kai" 
<kai.zheng@intel.com> 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:elecharny@gmail.com]
> Sent: Monday, January 25, 2016 11:58 PM
> To: Apache Directory Developers List <dev@directory.apache.org>
> 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

Mime
View raw message