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,
DCR, MRU)
- 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
that)
- 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 !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
