Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (herse.apache.org: domain of ole.ersoy@gmail.com designates
 64.233.162.227 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=tifyMkl9YKYF0fRBHzIU3tM9qJ9yo3H4apeUX2wo/uIhdKQT4CPym1WVh562NaIUQGE6aWjoCm2XjBTC/caar4p15vkTTpGd80/ssHEkoIV5XM4uc0+8W/lUiO7EnpvOBLOJbxTaursBRKNH6BpdTLn+PGAs0dDDHDpaCTf7t6w=
Message-ID: <4622439D.108@gmail.com>
Date: Sun, 15 Apr 2007 10:24:13 -0500
From: Ole Ersoy <ole.ersoy@gmail.com>
User-Agent: Thunderbird 1.5.0.10 (X11/20070302)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [Shared] shared-ldap is a mess
References: <a32f6b020704130419t2692896dycbeb4e1a5e1d4796@mail.gmail.com>
	 <d45b08f00704130438r5ece715cj4735f38a7b52a4c@mail.gmail.com>
 <a32f6b020704150803u934f1co342088c326530695@mail.gmail.com>
In-Reply-To: <a32f6b020704150803u934f1co342088c326530695@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


SNIP

> (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?

How about this?

We start with fresh Utility Classes.

Each class is centered around a core concern,
such as:

Navigation
IO (create, read, update, delete)
Parsing

Each method that goes in these
classes has to be well documented (javadoc)
and tested (All corner cases
and edge conditions).

We also follow an agreed upon set of conventions
for defining the Utility packages and Class Names (And Ideally
class members, but that requires more discussion to find
conventions that are acceptable to all I think).  I also
need to look at Jakarta commons to see if they have other
methodology that could be useful.

We then generate Javadoc and put it in a central
place, so that utility concern classes and methods
are visible.

When one of us needs a utility, and can't find it in the new shared 
utilities, we ask on the mailing list

If no-one responds,
the person needing it creates it
and puts it in an existing utility class,
or creates a new class corresponding to a new
concern area.

This allow a clean utility library to grow as needed
by the team.  I think it's essentially option [2].

Old utility methods can be replaced gradually.  We just
need to map old utility methods to the new ones, so that
we know what to update.

Thoughts?

Cheers,
- Ole