Re: [Client API] Ldap connection object

[Emmanuel Lecharny <el...@apache.org>]

Let's start with the LDAP connection.

Having it as a simple object is natural. It will be named LDAPConnection 
(the same name as the jLDAP API, so that people using it won't be lost).

This object will carry all the operations : abandon, add, bind, compare, 
delete, modify, modifydn search and unbind. We should also be able to 
manage extended requests.

Before sening any LDAP request, the user will have to connect (ie, 
create a new socket).

A question would be : do we have to rename some operation like modifyDN 
to simplest methods like rename, move, moveAndRename ? I'm leaning 
toward this direction, just because the semantic is easier to handle.

What should we manage in the connection otherwise ? Obviously, SSL and 
StartTLS. SSL could be set using a parameter in the parameter, like 
LDAPConnection.useSSL( true ); Configuration is also important. We will 
need to expose many other parameters (limits, timeout, Controls)

I will try to whip a quick class and post it so that we can discuss it 
and validate it.

 

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: [Client API] Ldap connection object

[Emmanuel Lecharny <el...@apache.org>]

Stefan Seelmann wrote:
> It would be cool configure a connection with default parameters, that
> are used as default for operations. For example the connection could be
> configured with a default search size limit that is used for each search
> request (but could be overwritten of course).
>   
Totally agree. One other thing we _must_ have is a connection pooling 
mechanism.
> Some methods I have in mind:
>
> setDefaultSearchSizeLimit(int)
> setDefaultSearchTimeLimit(int)
> setDefaultSearchScope(some Enum)
> setDefaultSearchBase(String dn / LdapDN dn)
> setDefaultSearchAttributes(String..attributes)
>
> setDefaultDerefAliasMethod(some Enum)
> setDefaultReferralsHandlingMethod(some Enum)
>   
Yeah, definitively a good idea. I will add those methods to the 
connection class.
> I think for controls it makes sense to define them per operation type
> because most controls only make sense for a specific operations:
> setDefaultSearchControls(Controls..controls) - like paged search
> setDefaultDeleteControls(Controls..controls) - like tree delete control
> etc.
>   
Well, I think that it's better to have the Controls added to each 
operation object, like BindRequest, SearchRequest...

For instance, you do a
BindRequest br = new BindRequest();
...
br.addControl( c1 );

Then you call the bind method :

connection.bind( br );

The addControl can use varargs, so you can do addControl( c1, c2, ...)

wdyt ?


-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: [Client API] Ldap connection object

[Stefan Seelmann <se...@apache.org>]

Emmanuel Lecharny wrote:
> Let's start with the LDAP connection.
> 
> Having it as a simple object is natural. It will be named LDAPConnection
> (the same name as the jLDAP API, so that people using it won't be lost).
> 
> This object will carry all the operations : abandon, add, bind, compare,
> delete, modify, modifydn search and unbind. We should also be able to
> manage extended requests.
> 
> Before sening any LDAP request, the user will have to connect (ie,
> create a new socket).
> 
> A question would be : do we have to rename some operation like modifyDN
> to simplest methods like rename, move, moveAndRename ? I'm leaning
> toward this direction, just because the semantic is easier to handle.
> 
> What should we manage in the connection otherwise ? Obviously, SSL and
> StartTLS. SSL could be set using a parameter in the parameter, like
> LDAPConnection.useSSL( true ); Configuration is also important. We will
> need to expose many other parameters (limits, timeout, Controls)
> 

It would be cool configure a connection with default parameters, that
are used as default for operations. For example the connection could be
configured with a default search size limit that is used for each search
request (but could be overwritten of course).

Some methods I have in mind:

setDefaultSearchSizeLimit(int)
setDefaultSearchTimeLimit(int)
setDefaultSearchScope(some Enum)
setDefaultSearchBase(String dn / LdapDN dn)
setDefaultSearchAttributes(String..attributes)

setDefaultDerefAliasMethod(some Enum)
setDefaultReferralsHandlingMethod(some Enum)

I think for controls it makes sense to define them per operation type
because most controls only make sense for a specific operations:
setDefaultSearchControls(Controls..controls) - like paged search
setDefaultDeleteControls(Controls..controls) - like tree delete control
etc.


Kind Regards,
Stefan