directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [Feedback needed] ADS pros and cons ?
Date Wed, 09 Jan 2008 15:15:59 GMT
This is excellent feedback Simon.  You make some very good points which our
version scheme was designed to support but we have not religiously adhered
to it.  This is a good time to point out why we must follow it and what it

Stable Bug Fix Branches

All new major releases start up a bug fix branch with a '0' for the minor
number: 1.0, 2.0, 3.0 .... Fixes in these branches are ONLY to fix bugs.  No
one should f**k around with API's or generics or what ever itch they get in
their arse that day.  I'm sick and tired of people taking this lightly and
causing a mess because they cannot control themselves.

Experimental Release Branches

Experimental release branches use a '5' for the minor number: 1.5,
2.5, 3.5.... Changes in these branches are not guaranteed to abide by
any contract.
The developers are free to do what they like and release from this branch as
they see fit within the legal framework of the ASF.  So massive changes are
allowed here. Any kind of tinkering is allowed here as long as we follow
some commitequette.

So this model will make people like Simon of which we have many happy.
However there are other factors that make this hard to do.  Basically this
is a balancing act between time and getting new features out in the server
to our users.

What happened with 1.0 and 1.5?

1.0 was our first release and most of us hate it.  I personally don't want
to work on it ever again because of the bad design decisions (I made most of
the time).  It's slower, less stable, less maintainable, and far too brittle
for my patience.  I feel my time and the time of others are better spent
fixing these limitations in 1.5.  However we did release a few bug fix
candidates.  Granted not as many as we wanted to but then again we're all

So what happened? We recommend that new people start using 1.5 instead
because even though it is experimental, it is much more stable and robust
than 1.0.  We kind of blurred our rules a little bit.

My Views, and Vision on Server Development

Servers are special.  They get started and have to stay up for a long a**ed
time.  So don't pick at them or be too liberal with changes to them. Once
you make a GA release just apply bug fixes to it and test the heck out of
it.  Stability is critical.

For example Studio is a client side application.  It can be started and
stopped when needed. So things like leaks and other problems do not compound
themselves into massive failures.  Months or years of uptime can do this.
Plus there's threading and other concurrency issues along with performance
aspects.  This is why the Studio release model does not need to follow the
same model as ApacheDS.

Linux is a great example. Linux had a great model for this before they got
all retarded with having to compete on the Desktop.  They used to have a
stable release branch with even minor numbers.  Remember these 2.2,
2.4, 4.2etc ... The experimental branches were using odd minor numbers
2.3, 2.5, 4.3 whatever.  This is because a server needs to be broken in and
have bugs and issues flushed out of new potentially destabilizing features.
The Linux Kernel Developers knew this.  But unfortunately since desktop
hardware changes very fast in comparison to server hardware they changed the
model to release newer versions as stable versions of the kernel to support
various motherboards etc.  So the Linux Kernel Project abandoned this model
to remain competitive.

We must also balance but don't nearly have it as hard as the Linux community
does since we're shielded by 2-layers of platforms (OS and Java).  So we can
follow our model.  However note that the start was rough for us because we
had to devise many experimental things from scratch.

ApacheDS is the first Java LDAP server.  1.0 was the first time this idea
was put to the test.  We started from scratch without previous experience or
a model to follow.  We just knew it could be done thanks to NIO. So many
ideas needed to change.  So I think we're going to be adhering much better
to our scheme of releases.  Also note that there will be less disparity
between major releases now that we have some major issues worked out.  Still
though many more remain.  Writing an LDAP server is more than I or anyone
else ever thought.  Furthermore we are trying to push LDAP to its limits and
make it more usable.  This is one of our primary directives.  So we are
dealing with concepts like Triggers and Stored Procedures.  It's just as
difficult if not more so to write properly than an RDBMS.

So things should get a little better for people in your place Simon as we
progress towards a more mature server.  Now that we've pretty much
implemented the protocol its more about the other software issues that we
have bandwidth to really handle properly.


On Jan 9, 2008 8:57 AM, <> wrote:

> 1)
> We embed ADS in JBoss along with our commercial middleware product.
> Our products are live in many large businesses throughout the UK and
> Europe.
> We use DS to support Single Sign On to our browser based applications.
> We use DS to manage a variety of information relating to message exchange
> between 'trading partners'.
> We install our products (inc. ADS) on IBM iSeries (OS400), IBM pSeries
> (AIX), Solaris, HP-UX, Linux and Windows Server platforms.
> 2)
> Pros:
> - It's java and can be embedded in JBoss.
> - The License allows redistribution within our product.
> - It has a reliable LDAP interface so our none java product can also
> maintain content.
> Cons:
> - Changes between revisions are so significant it makes it difficult to
> upgrade current installations.
>    - Persistent storage became incompatible between revisions causing
> support/upgrade problems.
> - Possible corruption of persistent storage when JVM is killed.
> - 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).
> - 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.
> - Significant interface changes between revisions has led to regular
> rework
> of our service container (our JBoss SAR implementation)
> 3)
> ** I'd prefer no new features combined with a long period of stability and
> maintenance **
> However, my top two improvements would be:
> - Solid, proven, replication implementation (mitosis?)
> - Alternative persistence providers ( J2EE data source or JPA Provider ? )
> 4)
> We are a commercial entity
> 5)
> ADS is very good and I like and respect the guys who work so hard to
> deliver it.
> - 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.
> - Fixes to ADS should be routinely applied to the stable release as well
> as
> the trunk.
> - I'm convinced that a well maintained, well document, long lived, stable
> release is the only way ADS will gain widespread commercial
> implementation.
> - SimonT
> 07 January 2008 16:01
> To: Apache Directory Developers List <>,
> cc:
> From: Emmanuel Lecharny <>
> Subject: [Feedback needed] ADS pros and cons  ?
> Hi !
> This is the very beginning of 2008, and we are all working hard to get a
> 2.0 out in the next few months. At this point, we think it's a good
> timing to get some feedback from you, users and developpers ! Here is a
> short list of question you may answer, but this is very up to you. We
> don't need names ( "I'm working for company XYZ" ), this is just
> informational.
> *Keep in mind that those informations will appear on the
> Apache ML and many other, so if you think that any confidential piece of
> it should not be disclose, then don't answer !*
> 1) What are you using ADS for ? Is it in production, used to do some
> tests during developpement, or simply as a toy ?
> 2) What are the Pros and Cons you clearly see ?
> 3) What would be the major features or improvement you are expecting to
> see in the near future ?
> 4) Are you a commercial entity, an non-for profit organization, an
> Apache project, a student or an individual just interested in the techno
> ? (no name needed)
> 5) Any other opinion or feedback you would like to share with us ?
> Thank you all for helping us being more aware !
> --
> --
> cordialement, regards,
> Emmanuel L├ęcharny

View raw message