Return-Path: 
 <dev-return-37907-apmail-directory-dev-archive=directory.apache.org@directory.apache.org>
X-Original-To: apmail-directory-dev-archive@www.apache.org
Delivered-To: apmail-directory-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 8AE683EC4
	for <apmail-directory-dev-archive@www.apache.org>;
 Thu, 28 Apr 2011 16:29:21 +0000 (UTC)
Received: (qmail 10071 invoked by uid 500); 28 Apr 2011 16:29:21 -0000
Delivered-To: apmail-directory-dev-archive@directory.apache.org
Received: (qmail 10026 invoked by uid 500); 28 Apr 2011 16:29:21 -0000
Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@directory.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@directory.apache.org>
List-Post: <mailto:dev@directory.apache.org>
List-Id: <dev.directory.apache.org>
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Delivered-To: mailing list dev@directory.apache.org
Received: (qmail 10019 invoked by uid 99); 28 Apr 2011 16:29:21 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Apr 2011 16:29:21 +0000
X-ASF-Spam-Status: No, hits=-0.0 required=5.0
	tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Received: from [209.85.210.178] (HELO mail-iy0-f178.google.com)
 (209.85.210.178)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Apr 2011 16:29:15 +0000
Received: by iyi12 with SMTP id 12so3127069iyi.37
        for <dev@directory.apache.org>; Thu, 28 Apr 2011 09:28:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.151.70 with SMTP id d6mr1565024icw.432.1304008134339; Thu,
 28 Apr 2011 09:28:54 -0700 (PDT)
Sender: mail@stefan-seelmann.de
Received: by 10.42.164.138 with HTTP; Thu, 28 Apr 2011 09:28:54 -0700 (PDT)
In-Reply-To: <4DB9924A.8090406@gmail.com>
References: <4DB94AA0.5030302@gmail.com>
	<BANLkTin+cGOjoMEWG-2vBbz5GCOFdsbF=A@mail.gmail.com>
	<4F5C26AF-2E6A-442C-A694-097C3851A62B@marcelot.net>
	<BANLkTikynDF40r74uHwvCSDDwM6yTWg9Qg@mail.gmail.com>
	<4DB97238.4060909@gmail.com>
	<BANLkTikJ=O1zr6zh03Dgqd2Tv2epQjVHrg@mail.gmail.com>
	<4DB97E10.9040701@apache.org>
	<A21FCA2F-AA19-4234-B512-B745C0827CB5@marcelot.net>
	<4DB98A21.4010500@gmail.com>
	<BANLkTi==79ywGaO9FoGQgwXc6O4w3MfAYg@mail.gmail.com>
	<BANLkTi=ODVuXeWGBaJkzAXrR73BwiVA3VQ@mail.gmail.com>
	<4DB9924A.8090406@gmail.com>
Date: Thu, 28 Apr 2011 18:28:54 +0200
X-Google-Sender-Auth: -Aq_9LSqhC7XoUUG6JJDYwhFaeE
Message-ID: <BANLkTi=Y66AkzK8Ryd=KY+d-=xS64MyTPw@mail.gmail.com>
Subject: Re: Search result in LDAP API
From: Stefan Seelmann <seelmann@apache.org>
To: Apache Directory Developers List <dev@directory.apache.org>
Content-Type: text/plain; charset=UTF-8

>
> This is not an easy choice.
>
> The problme is that the user might be puzzled to see that a
> LdapConnection.search( SearchRequest ) returns a cursor<SearchResponse> but
> that the LdapConnection.search( 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?

Kind Regards,
Stefan