directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject [LDAP] Problems defining client interfaces
Date Tue, 31 Mar 2009 15:13:25 GMT
Emmanuel and I have had a conversation regarding interface naming for the
the client module which imposes some subtle problems due to internal
interfaces present in the shared-ldap module.  The internal shared-ldap
classes representing LDAP request/response interfaces can be found in the
o.a.d.shared.ldap.message.  Some names in the package look like:


... etc

Now we're trying to devise simple stupid interfaces for public methods on
the LDAP client which exposes these interfaces to users of the client
library.  We want to make it really easy and clear to users by giving them
simple POJO/POJI to manipulate requests when simple operations on the
connection do not suffice.  So we want to use these names above but we don't
want the user of the client API to have to figure out which version to
import.  Obviously they will not be able to use one since connection.xxxx()
methods will require specific interfaces from the right package.

We thought the best thing to do is to use these simple interface and rename
the o.a.d.shared.ldap.message interfaces.  For lack of a better name we were
going to just place an 'I' in front of the interface.  In the past we
decided not to do this but this case is special.  However we might also
rethink using this convention in the future.  We could also rename these
interfaces to have an 'Internal' prefix.  We need to figure this out.

In general though this is what we would like to do with these
interfaces/classes: [use Add as example]

// simple user interface without all getter/setter pairs
public interface AddRequest
    String getEntry();

class AddRequestImpl extends InternalAddRequestImpl implements AddRequest

Note that a factory will be used (or connection will implement the factory),
to generate request objects of various types.  This will return back an
AddRequest.  The AddRequest will be a simplified view of the request data.
Things like the messageId will not be seen without casting the object to an
InternalAddRequestImpl.  No unnecesary object creation or copying is
required since the AddRequest returned is inherits from the internal class
and can be used to marshal and send over the connection.  We just use the
client interfaces to show a simplified view of the internal interfaces
without too much knowledge about their implementions.


View raw message