directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [Feedback needed] ADS pros and cons ?
Date Wed, 09 Jan 2008 15:22:33 GMT
Thanks a lot, Simon !

Some comments inline ... wrote:
> Cons:
>     - Persistent storage became incompatible between revisions causing
> support/upgrade problems.
We will offer some migration tools into 2.0 to migrate from 1.0/1.5 to 2.0.
> - Possible corruption of persistent storage when JVM is killed.
Very true. This is due to the way data are written on disk. We have a 
SynchOnWrite parameter which default to 14 seconds, but you can set it 
to 0 or -1 (I don't remember) to tell the server to immediatly write 
data on disk. This will slow down the writes, but this will guarantee 
against data corruptions (almost). Anyways, we have to work a little bit 
on this aspect, to offer the same protection of data against corruptions 
when the server crash, or at least a way to restore a consistant database.

We have some kind of 'subversion like' interceptor which may help to 
solve this problem. We currently use it to revert modifications in unit 
tests, but our intention is to include this capability to recover from a 
violent crash. This is expected in 2.0 too.
> - Switching JDK versions between ADS 1.0 and 1.5 made upgrade of many
> systems impossible (E.g. Upgrading JDK requires a new operating system
> version on some IBM platforms).
We won't switch to JDK 1.7 before a long period of time, be sure of that !
> - Bug fixes/patches are mainly applied to current trunk only which forces
> us to take the latest version (or SNAPSHOT!) to get defects resolved - the
> alternative being to maintain a branch of the source in-house which is
> something we always try to avoid for obvious reasons.
This is not exactly true. We have two main 'branches' : 1.0 and 1.5.
The 1.0 branch is only used as a bug fix branch, and it moves (slowly) 
to 1.0.3.
The 1.5 branch has always be clearly (???) exposed as the 'unstable' 
branch, and is moving to a 'stable' 2.0 branch.

As the 1.5 branch is not considered as 'stable' (which means, in our 
terms, that we can add new features), working in trunk is not totally 

But it's not perfect... We have had passionate convos about this scheme, 
and at the end, we decided that 1.5 should be seen as a intermediate 
state from  1.0 and 2.0. This is the reason why we didn't delivered a 
1.1, 1.2,... versions).

So in your case, yes, building from the trunk is the way to go, and this 
is far from being perfect, I agree. Using SNAPSHOT is certainly not a 
good idea...

At some point in the future, we will try to avoid such situations, and 
to release intermediate versions (like 1.5.2, etc) to include some bug 
fixes. This is what we did with 1.5.1, a bug-fix release. We didn't had 
time to deliver a 1.5.2 for many reasons, one of them being that we have 
some broken installers, and as we are supposed to be multi-platforms, 
this is not an option to release under those conditions.

Sorry for this situation, this is obviously not a perfect one !
> - Significant interface changes between revisions has led to regular rework
> of our service container (our JBoss SAR implementation)
Very true. But this is also something we can't avoid at some point ...
> 3)
> ** I'd prefer no new features combined with a long period of stability and
> maintenance **
The very same for us :)

But the project is also very young, and unperfect. We are working on that...
> However, my top two improvements would be:
> - Solid, proven, replication implementation (mitosis?)
At some point, I _think_ mitosis is somehow stable, but deserves more 
tests. For that, we need real world users !
> - ADS would benefit greatly from a sustained period of consolidation and
> stability - no new JDKs, no more changes to public interfaces, no massive
> refactoring exercises.
We are targeting this for 2.0. Consider that we have delivered 1.0 back 
in october 2005, almost 2 years ago !!! (I can't believe time is flying 
so fast ...) and 2.0 should be available in the next 6 months, that 
would be 2 years between each majors. Not that bad, when you consider 
that IBM delivers a new WebSphere every year ...
> - Fixes to ADS should be routinely applied to the stable release as well as
> the trunk.
We can't apply a bug fix to 1.5 and 1.0 at the same time, because the 
1.0 code base is really different from 1.5; We try as hard as possible, 
but we now consider 1.0 to be almost dead. The thing is that with the 
JVM change occured when we started the 1.5 version, it's quite difficult 
to maintain the same level of bug fixes in 1.0 and 1.5.

Now, 1.0 is by far less stable and slower than 1.5, and 2.0 should be 
much more stable and faster than 1.5 too. 2.0 should be considered as 
the next big thing, and should replace the 1.0 and 1.5 versions asap.

This is our target, in fact.

> - I'm convinced that a well maintained, well document, long lived, stable
> release is the only way ADS will gain widespread commercial implementation.
We totally agree. And this is what we are working on with 2.0. It should 
be the 'production ready' ADS.

I will add something very important : we don't exist without users, and 
without contributors. The frontier between users and contributor is very 
thin : it's just a matter of a few mails, patches, proposals, and of 
course dedication. All of our committers are people who at some point 
were users, and became committers, because they proposed patches and bug 

Thanks a lot for your comments, Simon, we really appreciated them !

cordialement, regards,
Emmanuel L├ęcharny

View raw message