Hi Emmanuel, On Fri, Jan 2, 2009 at 5:37 AM, Emmanuel Lecharny <[email protected]>wrote:
> Hi guys, > > as this is a new year, it's a good timing to define a realistic roadmap for > ADS 2.0. We did that last year back in august, trying to define a set of > small releases (from 1.5.1 to 1.5.9, targetting a 2.0-RC1), but we now need > to get more focused on what is essential. So here is a proposal, for > discussion ! > > I will gather all the items present in the previous roadmap into three > different lists : > 1) Mandatory : what we absolutely need for a 2.0 > 2) Good to have : what we want to have in a 2.0 if we have time to do it > 3) Not urgent : what we can push in a 2.5 release > Sounds good. > > So here is the list : > > 1) Mandatory > - Replication : we currently have something working (Mitosis), but we have > many aspects we want to check before releasing 2.0. So to speak : defining > something else than Derby as the pending operation storage, integrate Quartz > to manage scheduled operations, inject en entryUUID in each entry. Plus we > have to define some test scenarios. > > - Disaster Recovery System (DSR) : this is absolutely a must have. If the > server crash for any reason, we must be able to recover the base. We have > the ChangeLog system written, which is a major part of the DSR, but we still > need to cover the other parts (how to recover, configuration). > > - Interface cleaning : we have to check all the common interfaces and clean > them. It's not necessarily a costly task, but as we will freeze the API, we > have to do that before 2.0-RC1 > > - Documentation : This is also an something we must deliver. Documentation > is not only good for our users, it's also good for us, as developpers, > because writtng documentation helps to see where the API is not consistent. > > - VSLDAP : We would like to pass the STANDARD test this year. That should > not be too complicated. > > - JIRA cleaning : we have many open issues, some of them are 3 years old. > We have to check all the issues (208 as of today !), and decide which are > dead (sometime, an issue is opened, and is not anymore valid a few months > after, not because we have fixed it, but because it's not relevant anymore) > > > 2) Good to have > - Jetty integration : we need it for two different things at least : DSML > gateway and an Http based UI for monitoring the server > > - Trace/Logging interceptor : should not be too complex, as it will be > based on the changeLog interceptor (except that we also want to log every > search and bind requests) > > - ChangeLog extended operations : we need to add some Extended Operation to > allow users to drive the Change Log system (like reverting to a specific > revision, etc) > > - Authz Control : this is important if we want to allow the replication > system to deal with users right when replicating, or for the DSML gateway > > - Password Policy : it's a cool thing to have > > 3) Not urgent > - Encrypted user Password : the code is almost ready, but I'm not sure it's > urgent > > - CommandLine tools : well, who uses them ? > > - SP, Triggers : They are already working, if we want to improve the code > (for instance, allowing Groovy to be used), I think it should be done for > 2.5 > > - Group and Role cache : not really urgent. When we will work on TripleSec, > then it will be time ! > > - Attribute tags : we would like to have this, but it's a pretty big change > in the server. > > - AD authentication : same thing, we would like to have it, but it does not > worth postponing 2.0 for ever > > - Schema entities : Important, but in LDAP, currently, nobody uses it ... > > - Kerberos : I think that we can spawn a new project for kerberos, as soon > as ADS 2.0 is out. Kerberos can be a standalone server, based on ADS, at > some point. > > - DHCP, DNS : Does it need to be an ADS project? I was thinking about > moving them to MINA... As we already have a FTP server, plus a SSH server in > MINA, it seems to make sense. > > > That's pretty much it. Let's start the discusiion ! > I need to get back up to speed here after my absence. I'm a newbie now. The list is just perfect IMHO. I'm going to try to keep being involved in these discussions while attempting to chew off small tasks at first. I think revamping the UUID system so the UUID operational attribute is always created and maintained for entries regardless of replication being enabled is a good start along with fixing some bugs. I guess I need something creative along with bug fixing. Regards, Alex
