directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject Re: Search result in LDAP API
Date Thu, 28 Apr 2011 18:35:56 GMT
On 4/28/11 8:21 PM, Stefan Seelmann wrote:
> On Thu, Apr 28, 2011 at 8:08 PM, Emmanuel Lecharny<>  wrote:
>> On 4/28/11 6:28 PM, Stefan Seelmann wrote:
>>>> This is not an easy choice.
>>>> The problme is that the user might be puzzled to see that a
>>>> SearchRequest ) returns a cursor<SearchResponse>
>>>>   but
>>>> that the base, filter, scope, attrs... ) returns a
>>>> cursor<Entry>.
>>>> Using send( Request ) instead first makes the API lighter (we don't have
>>>> to
>>>> create one send() method per type of request, it can be hidden in the
>>>> LdapConnection class) and it's also for advanced users.
>>> Another idea: We have two interfaces: LdapConnection and
>>> LdapAsyncConnection. What about a third interface (e.g.
>>> AdvancedLdapConnection, need to find a better name) which extends
>>> LdapConnections. Then we can move all the methods for advanced users
>>> to this new interface. Then the LdapConnection interface is much
>>> smaller. We still can have a single LdapNetworkConnection class that
>>> implements all three interfaces.
>>> Thoughts?
>> Hmmm, that would be shitty... I tried to apply this modification on the
>> existing code, but sadly, we have two different implementations,
>> LdapCoreSessionConnection and LdapNetworkConnection. The first implements
>> LdapConnection, the second one implements LdapAsyncConnection.
>> Changing this would create a lot of problems...
>> Maybe we should keep it simple : search( SearchRequest ) returning a
>> SearchCursor for advanced users, and search( base, filter, scope, attrs...)
>> returning a Cursor<Entry>  for normal users.
>> wdyt ?
> Yes, I agree.
Ok, here is what I'm going to do :
- keep it as simple as possible, by just changing the return type for 
the moment

we can discuss further for other options, but at least, we will have 
something simple enough to start with.

Emmanuel L├ęcharny

View raw message