Hi Emmanuel,

On Fri, Jan 2, 2009 at 5:37 AM, Emmanuel Lecharny <elecharny@gmail.com> 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.