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.
