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:

BindRequest
BindResponse
AddRequest 
AddResponse
CompareRequest
CompareResponse
DeleteRequest
DeleteResponse

... 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.

Alex