directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Entry API
Date Thu, 04 Feb 2010 19:54:22 GMT
On Thu, Feb 4, 2010 at 8:38 PM, Emmanuel Lecharny <>wrote:

> Hi,
> here are some preliminary thoughts about the Entry class.
> The Entry class
> ---------------
> It's the base data structure representing an element stored into a LDAP
> server. It has a name (a DN) and some attributes.
> All the existing API use the same name, Entry (or LDAPEntry), except JNDI
> which has no such class (it uses Attributes but without a DN) and this class
> contains at least those two inner elements :
> - a DN
> - a set of Attribute
> There is some difference though as this element is either an Interface
> (ADS, ODS) or a Class (UID, jLdap)
> ODS define an implementing class named SortedEntry, which does not make a
> lot of sense, IMO. ADS class hierarchy is even more complex, as there are
> two lower interfaces (ClientEntry and ServerEntry) with two implementing
> classes (DefaultClientEntry and DefaultServerEntry). Overkilling … (and will
> be rewritten soon)
I'd be careful to remove interfaces.  As an API you have to allow the
broadest range of implementation possibilities. Interfaces are good to have.
 When in doubt keep the interface.

All in all, I'm wondering if it's a good idea to have an interface instead
> of a class, as it does not make a lot of sense to implement some different
> version of such an object.
It's hard to foresee the future here.  You've got to watch out when you're
trying to prognosticate the future while designing an API.

Just my two cents.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message