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 (hermes.apache.org: domain of aok123@bellsouth.net
 designates 205.152.59.70 as permitted sender)
Message-ID: <42783CF5.4030301@bellsouth.net>
Date: Tue, 03 May 2005 23:09:41 -0400
From: Alex Karasulu <aok123@bellsouth.net>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: Restructuring Partition API
References: <20050503233131.178FE13FA6@mail.vergenet.com>
In-Reply-To: <20050503233131.178FE13FA6@mail.vergenet.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Endi Sukma Dewata wrote:

> Hi,
>
> I�m proposing some changes to the Partition API. The changes include:
>
Hi Endi.

>     * Moving partition-related classes to
>       org.apache.ldap.server.partition. This is to provide a cleaner
>       Partition API, separate from other classes.
>
+1

>     * Renaming interface ContextPartition to Partition. This is just
>       to avoid confusion with the new class called PartitionContext.
>       See next item.
>
>     * Creating new interfaces PartitionConfig and PartitionContext.
>       This is similar to ServletConfig and ServletContext. The
>       PartitionConfig holds the configuration information for each
>       partition. The PartitionContext provides information about the
>       context in which the partition is running (i.e. the server).
>
Why may I ask is the PartitionContext needed? What kind of info besides 
the dn of the context for the partition is needed?

>     * Creating new class GenericPartitionConfig and
>       GenericPartitionContext. These classes provide the default
>       implementation of PartitionConfig and PartitionContext. These
>       classes are only used internally, they won�t be exposed in the API.
>
Ok yah makes sense once its clear for why we want a PartitionContext.

>     * Creating a new class AbstractPartition that implements
>       Partition. This becomes the base class for all partitions.
>
Hmm what goes into AbstractPartition - what can we stuff in there now 
that you move JDBM stuff down an extra notch in inheritance hierarchy?

>     * Renaming AbstractContextPartition to AbstractDbPartition and
>       make it extends the AbstractPartition. This becomes the base
>       class for all partitions using the JDBM database (e.g.
>       ApplicationPartition and SystemPartition).
>
How about calling it AbstractJdbmPartition?

> Note that these changes won�t be backward compatible, so those who 
> have implemented custom partition would need to fix their code a 
> little bit. But things should become simpler now, you don�t have to 
> implement an interface anymore, you can just extend from the base class.
>
Any thoughts from others regarding these changes?

> Any suggestions? Comments? Please let me know if this is ok. I will 
> submit a patch that includes these changes and also the documentations 
> (xdocs). Thanks a lot.
>
Alex