directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Boorshtein <mboorsht...@yahoo.com>
Subject Re: Restructuring Partition API
Date Wed, 04 May 2005 03:25:12 GMT
I've got a novel idea.  What about eliminating
partitions?  Partitions as they are known now would
break down into 2 pieces:

1.  Implementations as interceptors
2.  Backends would become "place holders"

This would allow you to do things like have a local
datastore for add/modify/delete/rename/get, but use an
jndi adapter for binds.

marc


--- Alex Karasulu <aok123@bellsouth.net> wrote:
> 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
> 
> 
> 

Mime
View raw message