directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Entry API
Date Thu, 04 Feb 2010 18:38:52 GMT
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)

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.

Constructors
------------

Here are the current implementations :

ADS :
DefaultClientEntry()
DefaultClientEntry(LdapDN)
DefaultClientEntry(LdapDN, EntryAttribute...)
DefaultClientEntry(LdapDN, String...)
DefaultServerEntry(SchemaManager)
DefaultServerEntry(SchemaManager, Entry)
DefaultServerEntry(SchemaManager, LdapDN)
DefaultServerEntry(SchemaManager, LdapDN, AttributeType, String)
DefaultServerEntry(SchemaManager, LdapDN, AttributeType...)
DefaultServerEntry(SchemaManager, LdapDN, ServerAttribute...)
DefaultServerEntry(SchemaManager, LdapDN, String...)

jLdap :
LDAPEntry()
LDAPEntry(String)
LDAPEntry(String, LDAPAttributeSet)

JNDI :
N/A

OpenDS :
SortedEntry()
SortedEntry(DN)
SortedEntry(Entry)
SortedEntry(String)
SortedEntry(String...)

UID :
Entry(DN)
Entry(DN, Attribute...)
Entry(DN, Collection<Attribute>)
Entry(String)
Entry(String, Attribute...)
Entry(String, Collection<Attribute>)
Entry(String...)


Quite complex :/ The problem here is that we would like those entries to 
be schema aware. The question is : how to make it simple for the user to 
create a schema aware entry? Either the entry comes from the server he 
is connected to, or he creates new entries on the client before sending 
them to the server. In both cases, the entry has to know about the schema.

Let's first assume that it's the case. The minimal list of constructors is :
Entry() : an empty constructor
Entry(DN)
Entry(String) : The DN is a string
Entry(DN, Attribute…)
Entry(String, Attribute…)
Entry(String…) : A special constructor which takes a list of strings 
representing a LDIF form of the entry

All those constructors will assume that the default schema will be used.

We can then inject a Schema by adding it to the constructor :
Entry(SchemaManager) : an empty constructor
Entry(SchemaManager, DN)
Entry(SchemaManager, String) : The DN is a string
Entry(SchemaManager, DN, Attribute…)
Entry(SchemaManager, String, Attribute…)
Entry(SchemaManager, String…) : A special constructor which takes a list 
of strings representing a LDIF form of the entry

Thoughts ?

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com



Mime
View raw message