directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Alderson <Martin.Alder...@salfordsoftware.co.uk>
Subject RE: [Client API] Bind Operation
Date Tue, 31 Mar 2009 15:56:49 GMT
This sounds much more reasonable than having overloads for everything.  I use jLDAP quite a
lot at work and I always shudder when I look a the javadoc for it.  It looks far more complex
then it really is, with so many overloads for each operation.  Their bind operation has 12
overloads!  Okay, 4 are deprecated, but still...

I was thinking of something more along the lines of having two overloads for every operation,
one with just the required arguments and the other with an extra Options argument which would
be an object containing all options specific to that operation.  The options would include
the constraints, the controls and even the listener for non-blocking calls.

An example:

  BindOptions bindOptions = new BindOptions();
  bindOptions.setPassword(password);
  bindOptions.setTimeLimit(10000);
  bindOptions.setControls(controls);
  connection.bind(userDN, bindOptions);

One thing that could be done to make it easier for the user to specify these extra arguments
is to use chainable setters as popularised by jQuery (I think!) which could give us something
like:

  connection.bind(userDN, new BindOptions().setPassword(password).setTimeLimit(10000).setControls(controls));

But this might not be seen as in keeping with the java spirit...

Martin



> We have had a convo with Alex (as he is in Paris atm, we have many convo
> about many parts of the server). What we came with is the few following
> idea :
> we can split the API in two categories : a few methods will be used 90% of
> the time, the 10% remaining will be for more specific cases. We should
> design the API so that using the 90% most used methods should be as simple
> as possible.
> 
> If we think about the Bind operation, that means that we can split the
> methods as :
> * simple
> bind() : anonymous bind
> bind(name, credentials) : bind with a principal
> * complex
> sasl bind
> bind( name ) : specific unauthenticated RFC operation bind with controls
> non blocking bind
> 
> The complex Bind can use a BindRequest parameter, up to the user to feed
> this POJO.
> 
> Here is how we see the API now :
> 
> Simple :
> BindResponse bind();
> BindResponse bind( String name, String password);
> 
> Complex, blocking :
> BindResponse bind( BindRequest bindRequest ); // handle simple or SASL
> BindResponse bind( BindRequest bindRequest, Control[] controls ); //
> handle simple or SASL, with controls
> 
> Complex, non blocking :
> void bind( BindRequest bindRequest, BindListener listener ); // handle
> simple or SASL void bind( BindRequest bindRequest, Control[] controls,
> BindListener listener ); // handle simple or SASL, with controls
> 
> The last issue is about the BindRequest POJO, as we already have an
> interface named BindRequest in shared. We think that renaming this
> interface to IBindRequest would be a solution.
> 
> thoughts ?
> 
> --
> --
> cordialement, regards,
> Emmanuel L├ęcharny
> www.iktek.com
> directory.apache.org
> 


Mime
View raw message