directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject 2.0.0-M3 roadmap and future evolutions ...
Date Tue, 16 Aug 2011 09:06:29 GMT
Hi guys,

so now that the 2.0.0-M2 vote is on its way, it's also time to discuss 
about what we want to put into the M3.

We have been a bit late, as we expected to release this version at least 
two weeks earlier, but we have been slowed down by some big issues in 
the replication sub-system.

If we think about what's missing, we can list :
- MMR : currently, we have implemented the Master/Slave system, we now 
need to implement the conflict resolution system. There is also one
feature we must improve : currently, we send a specific control for
MODDN operations to avoid sending all the moved entries. OpenLDAP
does not support this control, so we must also implement the standard
processing of MODDN operations.
- OSGi for the server
- HBase implementation
- removal of the one-level/sub-level index (see Stefan's mail, it opens 
some really interesting perspectives)

There are some other missing parts, but we don't have the power to 
process them in M2 :
- review the alias implementation
- review the administrative model implementation
- add the missing schema element we don't actually support (NF, DSC, 
- review the kerberos implementation
- switching to enryUUID as a key to reference entries in the 
MasterTable, instead of Long. That would allows us to conveniently 
refers to entries cross partitions
- implement cross partitions move operations (this is not supported atm)

This can be moved to M4, IMO.

I may have missed some items, so feel free to extend the list here.

Al in all, we can probably cut a new release pretty soon, keeping the 
pace high by working on limited features instead of moving all directions.

Regarding the LDAP-API component, we have some urgent tasks on our plate :
- pursue the modularization of the schema, making it completely 
standalone. Ideally, it should be an OSGi service
- split the module in two parts : a ldap-comons module, used by the 
server, studio and the ldap-api, and a ldap-api module, totally 
standalone, which exposes the API to users.

The second point is most certainly necessary. At this point, we have a 
mix of things in shared that are of no interest for the client, for 
instance. I'm not sure it will take more than a couple of days though.

We also have to add some documentation on the API ( a task I stared 2 
months ago, but it's still in its infancy).

Last, not least, we need to improve the kerberos documentation. Many 
users complain about it. The truth is that we fixed some blocking issues 
those last weeks, bugs that were killing our implementation as a valid 
candidate for a production kerberos server. But bugs are bugs, we can 
fix them. OTOH, with a pathetic documentation, we can't expect to have 
users testing the kerberos server, and giving us some feedback about 
problems they found in the code. Sadly, we need some workforce to deal 
with this problem...

Last, not least, in the past two weeks, we discussed a lot with Kiran 
about the Journal (used by the replication system) and the way it works. 
We need to conduct some experimentation in those areas :
- a fast and safe Journal. We have looked to KahalDB (the ActiveMQ 
journal), Derby log journal and a couple of other solutions. They all 
have issues (like the total lack of doc/javadoc for KahalDB, or the 
tight coupling with the code they are used in)
- a MVCC implementation for the backend (HawtDB could be a good base for 
- a transaction system
- a non-recursive AVLTree implementation

All those parts aren't urgent, and are probably more like research 
subjects, but anyway, it's important to mention that we need them in the 
long term. In other words, I'm emitting a signal for students or people 
considering entering the OSS world but don't know how to address such a 
big code base that it's a good way to be involved !

Ok, that's enough of a brain dump for the day, feel free to add your 
vision to this thread !

Thanks !

Emmanuel L├ęcharny

View raw message