directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tony Stevenson <>
Subject Re: Toward 2.0...
Date Sat, 03 Jan 2009 16:35:11 GMT

It's good to see some of these things on the list.  However one or two 
of these will be required should we decide to use ADS for the ASF.  I 
know we will be able to get a good basic LDAP service in place without 
some of these, *but* some are core requirements to the implementation of 
ADS within the ASF.

For example, the replication system will be one such core fundamental 
requirement.  In fact we cannot really proceed a lot further with the 
current demo/testing environment without it.  What state is it currently 

Also before LDAP goes live we will need some good basic documentation, 
which I can certainly help produce.  These will mainly focus on system 
runbooks, and who/what/where/how to make changes, stop/start services etc.

The DRS system is of interest to me. What happens at the moment if the 
system crashes?  Can we copy the flat files, daily, hourly?  Would they 
be re-usable. i.e. Could I copy the data files, and could they be used 
again if copied over the other files?   I am thinking about a backup 
strategy for the LDAP data.

I am happy tp help when and where I can, but I am not a developer.


On 02/01/2009 10:37, Emmanuel Lecharny 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
> 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 !
> Thanks !


Tony Stevenson  //

1024D/51047D66 ECAF DC55 C608 5E82 0B5E  3359 C9C7 924E 5104 7D66

View raw message