directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@gmail.com>
Subject Re: Toward 2.0...
Date Fri, 02 Jan 2009 23:17:48 GMT
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.

Regards,
Alex

Mime
View raw message