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 >
