directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [Shared] shared-ldap is a mess (was: Re: [JNDI] Utility Library)
Date Sun, 15 Apr 2007 15:03:45 GMT
On 4/13/07, Emmanuel Lecharny <> wrote:
> Alex is plain right. Shared-ldap is a mess, and I feel culprit about the
> part I have added into it.

Hey we all did our part in this area so don't blame yourself.

At some point, we should realize that fixing such a pile of sh*t is like
> trying to cure cancer with aspirin...

Hahaha.  I like that analogy.

However, as we will have to live with it for a little more time (say we can
> have a clean shared-ldap for 1.6), we should avoid as much as possible to
> add some more code, some more classes and some more aspirin ...

Well let's just add if it is not present.  Do some diligence to check if the
stuff we are adding has already been put in there.  This thing is so big
that it probably has what you need already in it.  If not something close is
there which can be better parameterized to handle your use case.

I will suggest that we put a new JIRA (cleaning shared-ldap) and start
> working on it just after ApacheCon EU. We can also drop some thoughts and
> proposal on a wiki page (Refactoring Shared-ldap) in the meanwhile.

Well you're right we're not going to fix it.  Perhaps a rewrite with 2.0 is
a good time to start with a clean shared API?  For now we should try to keep
the mess ass contained as possible?

Don't know myself just asking.

Many people want to use a clean API to interact with the server, and I must
> say I feel ashamed when I exhibit shared-ldap... Those guys working on
> LdapStudio are suffering every day because of this API.
> Let's clean the mess.

Well let's ask ourselves if this is the right time or if we should do some
small refactoring of this stuff.


(1) touch only as needed and contain until rewrite
(2) refactor gradually as best as we can without big bang or until we
realize that a big rewrite is needed later but still try to improve it
(3) ... any more ideas?


View raw message