You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@apache.org> on 2009/03/29 19:13:03 UTC
[Client API] Bind Operation
Hi,
some first thought about the bind operation. I propose 4 methods :
- bind() for an anonymous bind
- bind(String name) for an unauthenticated bind (this is a special case
described in RFC 4513, par 5.1.2)
- bind(String name, String credentials)
- bind(String name, byte[] credentials) Those two methods are standard
bind with a credential as a String or byte[]
We may define a few others, assuming we may want to use some controls.
We also have to deal with SASL bind.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [Client API] Bind Operation
Posted by Emmanuel Lecharny <el...@apache.org>.
>>>
>> In some way, we may consider every operation which returns a response to be
>> either synchronous or asynchronous. Of course, it makes more sense for
>> Search, but we might want to have the same mechanism for bind too.
>>
>> What I have in mind is something like that :
>> - each operation can be blocking or non-blocking
>> - if it's blocking, you get the whole response when the method returns (
>> for instance, resp = search( blah ), where resp might be an iterator )
>> - if it's not blocking, we should pass a listener as a parameter, and the
>> method will call the listener when done.
>> - in this case, we will need more than one listener, as each operation may
>> have its own listener, as you may have a non-blocking search, and a
>> non-blocking add at the same time, though.
>>
>> Right now, I would just make the bind request blocking, as all other atomic
>> operations, but keep the search blocking or non-blocking.
>>
>>
>
> I think the old Java Netscape API does this
It does :
|*bind
<http://developer.novell.com/documentation/jldap/jldapenu/api/com/novell/ldap/LDAPConnection.html#bind%28int,%20java.lang.String,%20byte%5B%5D,%20com.novell.ldap.LDAPResponseQueue%29>*(int version,
java.lang.String dn, byte[] passwd, LDAPResponseQueue
<http://developer.novell.com/documentation/jldap/jldapenu/api/com/novell/ldap/LDAPResponseQueue.html> queue)|
"Asynchronously authenticates to the LDAP server (that the object is
currently connected to) using the specified name, password, LDAP
version, and queue."
> but I am not sure it does this
> for all the LDAP operations. Regardless it does not hurt at all to have an
> additional overload just for the non-blocking mechanism.
>
Yup. Except that it takes more time to implement ;)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [Client API] Bind Operation
Posted by Alex Karasulu <ak...@gmail.com>.
Hi Emm,
On Tue, Mar 31, 2009 at 11:20 PM, Emmanuel Lecharny <el...@apache.org>wrote:
> So here is what I have from now on :
>
>
> Simple bind (blocking) :
> public LdapResponse bind() throws LdapException
> public LdapResponse bind( String name ) throws Exception
> public LdapResponse bind( String name, String credentials ) throws
> LdapException
> public LdapResponse bind( String name, byte[] credentials ) throws
> LdapException
>
For the common (90%) case perhaps just bind() and bind( String, String )
works no?
>
> Sasl and other complex operations (blocking and not blocking):
> public LdapResponse bind( BindRequest bindRequest ) throws LdapException
> public void bind( BindRequest bindRequest, BindListener bindListener )
> throws LdapException
>
Cool.
> I was trying to evaluate if it's a good idea to have bindSasl() methods,
> instead of having a generic bind( BindRequest). In this case, we will have
> this additional method :
> public LdapResponse bindSasl( String name, String mechanism, byte[]
> credentials ) throws LdapException
>
Yeah this helps with the simple case. People are using SASL more and more
these days. More common though people are using StartTLS. Maybe that's
something to keep in mind. But do we really need this in some kind of
simple case? Again we want to balance convenience with congestion to make
the API as easy to use and understand as possible.
Alex
Re: [Client API] Bind Operation
Posted by Emmanuel Lecharny <el...@apache.org>.
So here is what I have from now on :
Simple bind (blocking) :
public LdapResponse bind() throws LdapException
public LdapResponse bind( String name ) throws Exception
public LdapResponse bind( String name, String credentials ) throws
LdapException
public LdapResponse bind( String name, byte[] credentials ) throws
LdapException
Sasl and other complex operations (blocking and not blocking):
public LdapResponse bind( BindRequest bindRequest ) throws LdapException
public void bind( BindRequest bindRequest, BindListener bindListener
) throws LdapException
The non blocking operation is the last one, using the bindListener. I
also have added a timeout parameter into the BindRequest object, so that
a blocking request does not last forever.
I was trying to evaluate if it's a good idea to have bindSasl() methods,
instead of having a generic bind( BindRequest). In this case, we will
have this additional method :
public LdapResponse bindSasl( String name, String mechanism, byte[]
credentials ) throws LdapException
wdyt ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
[Client API] Abandon Operation
Posted by Emmanuel Lecharny <el...@apache.org>.
This is a simple one ! The only parameter we can set is the messageId.
We can have controls and a timeout. This is not a blocking or
non-blocking method, as it does not return a response.
I suggest the simple API :
public void abandon( int messageId ) throws LdapException
public void abandon( AbandonRequest abandonRequest ) throws
LdapException
The first one will be for the simple usages, if one want to add a
control or set a timeout, he should use the second method. And that's it.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [Client API] Bind Operation
Posted by Emmanuel Lecharny <el...@apache.org>.
Martin Alderson wrote:
>> I like this BindOption class, it's much better than LDAPConstraints. But I
>> think it should be associated with the BindRequest object, to keep the
>> bind() method as simplest as possible. Using your sample, that would gives
>> :
>>
>> BindOptions bindOptions = new BindOptions();
>> bindOptions.setTimeLimit(10000);
>> bindOptions.setControls(controls);
>> BindRequest bindRequest = connection.createBindRequest();
>> bindRequest.setOptions( bindOptions );
>> bindRequest.setName( userDN );
>> bindRequest.setPassword( password );
>>
>> connection.bind( bindRequest );
>>
>> For a simple bind, it would be much simpler :
>>
>> connection.bind( userDN, password );
>>
>
> But this is getting a bit heavyweight. If you start off using the simple:
>
> connection.bind( userDN, password )
>
> then later on you decide you want to specify a time limit for this bind operation you then have to change it to:
>
> BindOptions bindOptions = new BindOptions();
> bindOptions.setTimeLimit(10000);
> BindRequest bindRequest = connection.createBindRequest();
> bindRequest.setOptions( bindOptions );
> bindRequest.setName( userDN );
> bindRequest.setPassword( password );
>
> connection.bind( bindRequest );
>
> ... all that just to specify a time limit. Its suddenly gone from being very simple and clear to a big chunk of code.
>
Yes, this is heavy, but when it comes to defining specific parameters,
like TimeLimit for a BindRequest, I don't think it's really used often.
So I'm keen to sacrifice it...
> I would at least like to see the BindRequest and BindOptions objects merged.
>
This is an option. We may not need this BindOption class anyway...
> I suspect that we're looking at this from two different perspectives - you from the design (making sure everything is in its logical place) and me from the code (ease of reading, writing and modifying). I think both are important but they seem to be conflicting a bit here.
>
Well, my perspective is _really_ the user's one. I want the user to find
the API easy to use for 90% of the case, and for the bind() operation, I
think that bind() and bind(name, password) will be the used operations
(probably more tha 90% of the time).
But I may be wrong, or the perception might be slightly off base, thus
those mails :)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
RE: [Client API] Bind Operation
Posted by Martin Alderson <Ma...@salfordsoftware.co.uk>.
> I like this BindOption class, it's much better than LDAPConstraints. But I
> think it should be associated with the BindRequest object, to keep the
> bind() method as simplest as possible. Using your sample, that would gives
> :
>
> BindOptions bindOptions = new BindOptions();
> bindOptions.setTimeLimit(10000);
> bindOptions.setControls(controls);
> BindRequest bindRequest = connection.createBindRequest();
> bindRequest.setOptions( bindOptions );
> bindRequest.setName( userDN );
> bindRequest.setPassword( password );
>
> connection.bind( bindRequest );
>
> For a simple bind, it would be much simpler :
>
> connection.bind( userDN, password );
But this is getting a bit heavyweight. If you start off using the simple:
connection.bind( userDN, password )
then later on you decide you want to specify a time limit for this bind operation you then have to change it to:
BindOptions bindOptions = new BindOptions();
bindOptions.setTimeLimit(10000);
BindRequest bindRequest = connection.createBindRequest();
bindRequest.setOptions( bindOptions );
bindRequest.setName( userDN );
bindRequest.setPassword( password );
connection.bind( bindRequest );
... all that just to specify a time limit. Its suddenly gone from being very simple and clear to a big chunk of code.
I would at least like to see the BindRequest and BindOptions objects merged.
I suspect that we're looking at this from two different perspectives - you from the design (making sure everything is in its logical place) and me from the code (ease of reading, writing and modifying). I think both are important but they seem to be conflicting a bit here.
Martin
Re: [Client API] Bind Operation
Posted by Emmanuel Lecharny <el...@apache.org>.
Martin Alderson wrote:
> 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);
>
I like this BindOption class, it's much better than LDAPConstraints. But
I think it should be associated with the BindRequest object, to keep the
bind() method as simplest as possible. Using your sample, that would gives :
BindOptions bindOptions = new BindOptions();
bindOptions.setTimeLimit(10000);
bindOptions.setControls(controls);
BindRequest bindRequest = connection.createBindRequest();
bindRequest.setOptions( bindOptions );
bindRequest.setName( userDN );
bindRequest.setPassword( password );
connection.bind( bindRequest );
For a simple bind, it would be much simpler :
connection.bind( userDN, password );
> 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));
>
Yuk ... Never liked it... but it may be just me ;)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [Client API] Bind Operation
Posted by Alex Karasulu <ak...@gmail.com>.
Thanks Emmanuel for doing this even though you don't like it.
Alex
On Wed, Apr 1, 2009 at 11:53 AM, Emmanuel Lecharny <el...@apache.org>wrote:
> Martin Alderson wrote:
>
>> 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));
>>
>>
> You and Alex convinced me that this chain concept, even if I don't like it,
> should be present, for those who want to use it. Anyway, it's a no brainer
> to implement. Wait... The commit has already been pushed ;)
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: [Client API] Bind Operation
Posted by Emmanuel Lecharny <el...@apache.org>.
Martin Alderson wrote:
> 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));
>
You and Alex convinced me that this chain concept, even if I don't like
it, should be present, for those who want to use it. Anyway, it's a no
brainer to implement. Wait... The commit has already been pushed ;)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
RE: [Client API] Bind Operation
Posted by Martin Alderson <Ma...@salfordsoftware.co.uk>.
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
>
Re: [Client API] Bind Operation
Posted by Emmanuel Lecharny <el...@apache.org>.
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
Re: [Client API] Bind Operation
Posted by Kiran Ayyagari <ay...@gmail.com>.
Emmanuel Lecharny wrote:
> One more thing :
>
> we must handle the controls within the bind operation. That could be
> done by adding an optionnal extra parameter, like jLDAP does (they are
> using LdapConstraints)
>
> This object contains :
> - a list of controls
> - size limit
> - time limit
> - referral handling
> - and a general property allowing you to send server specific parameters
> (I guess).
+1 for specific parameters, that avoids one more step of reading some external doc to understand this API.
(I still do a search for env parameter values while writing code to create a InitialContext :( )
On a other note, I think this client API would help me in my sandboxed work on Object LDAP mapping (currently from
schema-> POJO -> Server). Currently this is tightly coupled with CoreSession API.
I believe that once we get the client-api out then the OLM ( !! ;) ) project will benefit from it. as I need not provide
a client side binding in two different APIs (ADS core API, JNDI)
--
Kiran Ayyagari
Re: [Client API] Bind Operation
Posted by Emmanuel Lecharny <el...@apache.org>.
Alex Karasulu wrote:
> On Tue, Mar 31, 2009 at 2:22 PM, Emmanuel Lecharny <el...@apache.org>wrote:
>
>
>> One more thing :
>>
>> we must handle the controls within the bind operation.
>>
>
>
> Request controls should be added to the bind() method in an overload. As a
> List or Set (guess order does not matter).
>
This is an option. If we don't need to pass any other parameters like
TimeLimit, that should be enough. I would though pass another parameter
like the timeout (a client timeout). I don't know about SASL... till
have to check this guy.
Now, if we have more of those parameters, it would make sense to
encapsulate them into an class, otherwise we will have hundreds of
bind') overload ;)
>
>> That could be done by adding an optionnal extra parameter, like jLDAP does
>> (they are using LdapConstraints)
>>
>
>
> Controls are not constraints.
>
Constraints contain Controls, in jLDAP. It's a container in some way. I
don't like the name though ...
>
>
>> This object contains :
>> - a list of controls
>> - size limit
>> - time limit
>> - referral handling
>> - and a general property allowing you to send server specific parameters (I
>> guess).
>>
>>
>
> Some things like session controls belong in the session.
What are 'session controls' ? Controls are related to the operation,
aren't they? Or I'm missing something ?
> The session should
> also maintain defaults for these parameters which are search specific
> parameters mostly.
yup.
> Users should just be able to override these values on
> the connection while using a SearchControls object for per request overrides
> that one does not want overriding session wide settings in the
> LdapConnection.
>
That would be a potential problem when using syncrepl, as more than one
request can be send to the server, and in the meanwhile, another client
request can set another parameter into the connection. I would rather
define requests parameters, not defaulting to connection parameters. I
don't know... At least, I have not a fixed mind about that atm.
> Should we mimic this object ?
>
>
> I hate this object. It's in the Netscape Java LDAP API as well. I've
> always felt it was awkward to use.
>
Well we don't have thousands of possibilities here...
* something like LDAPConstraints (whatever the name is)
* a list of parameters (leading to a multiplication of the overloaded
methods)
* or instead of passing more than one parameter to the bind() method,
just pass a BindRequest parameter, as this object will contain all the
needed elements (including controls).
>> For instance, size limit and referral handling does not make too much sense
>> for a BindRequest.
>>
>>
>
> Ok I see what you mean. Yes we should be operation specific. This way we
> don't clutter things and the parameters together will make sense.
>
yeah. But that mean it's a bit less obvious to remember all the
parameters for each operation. Not an esay choice ...
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [Client API] Bind Operation
Posted by Alex Karasulu <ak...@gmail.com>.
On Tue, Mar 31, 2009 at 2:22 PM, Emmanuel Lecharny <el...@apache.org>wrote:
> One more thing :
>
> we must handle the controls within the bind operation.
Request controls should be added to the bind() method in an overload. As a
List or Set (guess order does not matter).
> That could be done by adding an optionnal extra parameter, like jLDAP does
> (they are using LdapConstraints)
Controls are not constraints.
> This object contains :
> - a list of controls
> - size limit
> - time limit
> - referral handling
> - and a general property allowing you to send server specific parameters (I
> guess).
>
Some things like session controls belong in the session. The session should
also maintain defaults for these parameters which are search specific
parameters mostly. Users should just be able to override these values on
the connection while using a SearchControls object for per request overrides
that one does not want overriding session wide settings in the
LdapConnection.
Should we mimic this object ?
I hate this object. It's in the Netscape Java LDAP API as well. I've
always felt it was awkward to use.
> Or should we simply allow operation specific elements ?
Sorry what do you mean?
> For instance, size limit and referral handling does not make too much sense
> for a BindRequest.
>
Ok I see what you mean. Yes we should be operation specific. This way we
don't clutter things and the parameters together will make sense.
Alex
Re: [Client API] Bind Operation
Posted by Emmanuel Lecharny <el...@apache.org>.
One more thing :
we must handle the controls within the bind operation. That could be
done by adding an optionnal extra parameter, like jLDAP does (they are
using LdapConstraints)
This object contains :
- a list of controls
- size limit
- time limit
- referral handling
- and a general property allowing you to send server specific parameters
(I guess).
Should we mimic this object ? Or should we simply allow operation
specific elements ? For instance, size limit and referral handling does
not make too much sense for a BindRequest.
wdyt ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [Client API] Bind Operation
Posted by Alex Karasulu <ak...@gmail.com>.
On Tue, Mar 31, 2009 at 12:42 PM, Emmanuel Lecharny <el...@apache.org>wrote:
> Alex Karasulu wrote:
>
>> On Tue, Mar 31, 2009 at 12:55 AM, Emmanuel Lecharny <elecharny@apache.org
>> >wrote:
>>
>>
>>
>>> Stefan Zoerner wrote:
>>>
>>>
>>>
>>>> Emmanuel Lecharny wrote:
>>>>
>>>> some first thought about the bind operation. I propose 4 methods :
>>>>
>>>>
>>>>> - bind() for an anonymous bind
>>>>> - bind(String name) for an unauthenticated bind (this is a special case
>>>>> described in RFC 4513, par 5.1.2)
>>>>> - bind(String name, String credentials)
>>>>> - bind(String name, byte[] credentials) Those two methods are standard
>>>>> bind with a credential as a String or byte[]
>>>>>
>>>>> We may define a few others, assuming we may want to use some controls.
>>>>> We
>>>>> also have to deal with SASL bind.
>>>>>
>>>>>
>>>>>
>>>> Looks good to me. What about the return value (is it void in all four
>>>> cases?) and the case that authentication fails. Throws it an exception,
>>>> and
>>>> if so, is it derived from RuntimeException (I hope so)?
>>>>
>>>>
>>>>
>>> First, let's talk about the return value. We have two cases :
>>> 1) authentication succeeded. We will get a BindResponse
>>> 2) authentication failed. We will also have a BindResponse, but in this
>>> case, you would like to get the cause, so it's not obvious to want an
>>> exception.
>>>
>>> So my best guest would be that it's better not to throw an exception.
>>>
>>> One more thing : we might want to get a non-blocking mode, where the
>>> BindResponse is not returned but a listener is invoked. We discussed that
>>> option with Alex, and right now, we think it's better to have a blocking
>>> mode for simple operations, and a non-blocking mode for search.
>>>
>>> Does it make sense ?
>>>
>>>
>>>
>>>
>> It does not make much sense to me to have asynchronous IO for bind. I may
>> be missing something though. Regardless I suggest we make sure we
>> consider
>> SASL early on for bind since this may impact the way we use it. As you
>> know
>> some operations require multiple bind request/response interactions to
>> negotiate the authentication. There is some kind of state now being
>> associated with the series of bind requests. In general sasl will have
>> some
>> impact on the bind() requiring at least some values to be returned,
>> especially when multiple bind req/resp pairs are needed for a single
>> authentication.
>>
>>
> In some way, we may consider every operation which returns a response to be
> either synchronous or asynchronous. Of course, it makes more sense for
> Search, but we might want to have the same mechanism for bind too.
>
> What I have in mind is something like that :
> - each operation can be blocking or non-blocking
> - if it's blocking, you get the whole response when the method returns (
> for instance, resp = search( blah ), where resp might be an iterator )
> - if it's not blocking, we should pass a listener as a parameter, and the
> method will call the listener when done.
> - in this case, we will need more than one listener, as each operation may
> have its own listener, as you may have a non-blocking search, and a
> non-blocking add at the same time, though.
>
> Right now, I would just make the bind request blocking, as all other atomic
> operations, but keep the search blocking or non-blocking.
>
I think the old Java Netscape API does this but I am not sure it does this
for all the LDAP operations. Regardless it does not hurt at all to have an
additional overload just for the non-blocking mechanism.
Alex
Re: [Client API] Bind Operation
Posted by Emmanuel Lecharny <el...@apache.org>.
Alex Karasulu wrote:
> On Tue, Mar 31, 2009 at 12:55 AM, Emmanuel Lecharny <el...@apache.org>wrote:
>
>
>> Stefan Zoerner wrote:
>>
>>
>>> Emmanuel Lecharny wrote:
>>>
>>> some first thought about the bind operation. I propose 4 methods :
>>>
>>>> - bind() for an anonymous bind
>>>> - bind(String name) for an unauthenticated bind (this is a special case
>>>> described in RFC 4513, par 5.1.2)
>>>> - bind(String name, String credentials)
>>>> - bind(String name, byte[] credentials) Those two methods are standard
>>>> bind with a credential as a String or byte[]
>>>>
>>>> We may define a few others, assuming we may want to use some controls. We
>>>> also have to deal with SASL bind.
>>>>
>>>>
>>> Looks good to me. What about the return value (is it void in all four
>>> cases?) and the case that authentication fails. Throws it an exception, and
>>> if so, is it derived from RuntimeException (I hope so)?
>>>
>>>
>> First, let's talk about the return value. We have two cases :
>> 1) authentication succeeded. We will get a BindResponse
>> 2) authentication failed. We will also have a BindResponse, but in this
>> case, you would like to get the cause, so it's not obvious to want an
>> exception.
>>
>> So my best guest would be that it's better not to throw an exception.
>>
>> One more thing : we might want to get a non-blocking mode, where the
>> BindResponse is not returned but a listener is invoked. We discussed that
>> option with Alex, and right now, we think it's better to have a blocking
>> mode for simple operations, and a non-blocking mode for search.
>>
>> Does it make sense ?
>>
>>
>>
> It does not make much sense to me to have asynchronous IO for bind. I may
> be missing something though. Regardless I suggest we make sure we consider
> SASL early on for bind since this may impact the way we use it. As you know
> some operations require multiple bind request/response interactions to
> negotiate the authentication. There is some kind of state now being
> associated with the series of bind requests. In general sasl will have some
> impact on the bind() requiring at least some values to be returned,
> especially when multiple bind req/resp pairs are needed for a single
> authentication.
>
In some way, we may consider every operation which returns a response to
be either synchronous or asynchronous. Of course, it makes more sense
for Search, but we might want to have the same mechanism for bind too.
What I have in mind is something like that :
- each operation can be blocking or non-blocking
- if it's blocking, you get the whole response when the method returns (
for instance, resp = search( blah ), where resp might be an iterator )
- if it's not blocking, we should pass a listener as a parameter, and
the method will call the listener when done.
- in this case, we will need more than one listener, as each operation
may have its own listener, as you may have a non-blocking search, and a
non-blocking add at the same time, though.
Right now, I would just make the bind request blocking, as all other
atomic operations, but keep the search blocking or non-blocking.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [Client API] Bind Operation
Posted by Alex Karasulu <ak...@gmail.com>.
On Tue, Mar 31, 2009 at 12:55 AM, Emmanuel Lecharny <el...@apache.org>wrote:
> Stefan Zoerner wrote:
>
>> Emmanuel Lecharny wrote:
>>
>> some first thought about the bind operation. I propose 4 methods :
>>>
>>> - bind() for an anonymous bind
>>> - bind(String name) for an unauthenticated bind (this is a special case
>>> described in RFC 4513, par 5.1.2)
>>> - bind(String name, String credentials)
>>> - bind(String name, byte[] credentials) Those two methods are standard
>>> bind with a credential as a String or byte[]
>>>
>>> We may define a few others, assuming we may want to use some controls. We
>>> also have to deal with SASL bind.
>>>
>>
>> Looks good to me. What about the return value (is it void in all four
>> cases?) and the case that authentication fails. Throws it an exception, and
>> if so, is it derived from RuntimeException (I hope so)?
>>
> First, let's talk about the return value. We have two cases :
> 1) authentication succeeded. We will get a BindResponse
> 2) authentication failed. We will also have a BindResponse, but in this
> case, you would like to get the cause, so it's not obvious to want an
> exception.
>
> So my best guest would be that it's better not to throw an exception.
>
> One more thing : we might want to get a non-blocking mode, where the
> BindResponse is not returned but a listener is invoked. We discussed that
> option with Alex, and right now, we think it's better to have a blocking
> mode for simple operations, and a non-blocking mode for search.
>
> Does it make sense ?
>
>
It does not make much sense to me to have asynchronous IO for bind. I may
be missing something though. Regardless I suggest we make sure we consider
SASL early on for bind since this may impact the way we use it. As you know
some operations require multiple bind request/response interactions to
negotiate the authentication. There is some kind of state now being
associated with the series of bind requests. In general sasl will have some
impact on the bind() requiring at least some values to be returned,
especially when multiple bind req/resp pairs are needed for a single
authentication.
Alex
Re: [Client API] Bind Operation
Posted by Emmanuel Lecharny <el...@apache.org>.
Stefan Zoerner wrote:
> Emmanuel Lecharny wrote:
>
>> some first thought about the bind operation. I propose 4 methods :
>>
>> - bind() for an anonymous bind
>> - bind(String name) for an unauthenticated bind (this is a special
>> case described in RFC 4513, par 5.1.2)
>> - bind(String name, String credentials)
>> - bind(String name, byte[] credentials) Those two methods are
>> standard bind with a credential as a String or byte[]
>>
>> We may define a few others, assuming we may want to use some
>> controls. We also have to deal with SASL bind.
>
> Looks good to me. What about the return value (is it void in all four
> cases?) and the case that authentication fails. Throws it an
> exception, and if so, is it derived from RuntimeException (I hope so)?
First, let's talk about the return value. We have two cases :
1) authentication succeeded. We will get a BindResponse
2) authentication failed. We will also have a BindResponse, but in this
case, you would like to get the cause, so it's not obvious to want an
exception.
So my best guest would be that it's better not to throw an exception.
One more thing : we might want to get a non-blocking mode, where the
BindResponse is not returned but a listener is invoked. We discussed
that option with Alex, and right now, we think it's better to have a
blocking mode for simple operations, and a non-blocking mode for search.
Does it make sense ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [Client API] Bind Operation
Posted by Stefan Zoerner <st...@labeo.de>.
Emmanuel Lecharny wrote:
> some first thought about the bind operation. I propose 4 methods :
>
> - bind() for an anonymous bind
> - bind(String name) for an unauthenticated bind (this is a special case
> described in RFC 4513, par 5.1.2)
> - bind(String name, String credentials)
> - bind(String name, byte[] credentials) Those two methods are standard
> bind with a credential as a String or byte[]
>
> We may define a few others, assuming we may want to use some controls.
> We also have to deal with SASL bind.
Looks good to me. What about the return value (is it void in all four
cases?) and the case that authentication fails. Throws it an exception,
and if so, is it derived from RuntimeException (I hope so)?
Greetings from Ingolstadt,
Stefan