Return-Path: 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 A62F6304B for ; Thu, 28 Apr 2011 20:31:22 +0000 (UTC) Received: (qmail 67495 invoked by uid 500); 28 Apr 2011 20:31:22 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 67453 invoked by uid 500); 28 Apr 2011 20:31:22 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 67446 invoked by uid 99); 28 Apr 2011 20:31:22 -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 20:31:22 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com designates 74.125.82.178 as permitted sender) Received: from [74.125.82.178] (HELO mail-wy0-f178.google.com) (74.125.82.178) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 28 Apr 2011 20:31:16 +0000 Received: by wyb33 with SMTP id 33so2928361wyb.37 for ; Thu, 28 Apr 2011 13:30:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=BnUQdxcaAxojm8JRiHyhxYOx8jF5/TucIgylUSAvCVk=; b=Zfqtx9xkkOO4qPOCNuLh4WECyYMO3aDrUIDfCzZJx7hTMXMqekUGr2A1ILV9M5cbut L4OQYEPX07ItVbvVb6y4UkAIuMBthUOJbL3iNxxdobIH93tPHGAVLaSJaiG+PUDdzPpp LX42OaaEdqY/ZbuArO0N7Nldo2H2aHuUKnz4s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=glVY3o+1Fm2Qpe4zSRaMP75bJDvSn/itBNa0QvYZ8NubzKPMPYjwfu8T0HRCs7d9Qm nrSs3GGRxfV4LyGuwTQ137SnVK1vKoFPRIkDXfSlqF1QoP9ZhuIp7rDCoPYSqbPBRJ9O Wy/l5gfii6T1Kw0rlSvOgiNYMzowcB96QZy70= MIME-Version: 1.0 Received: by 10.216.152.170 with SMTP id d42mr1425610wek.39.1304022654740; Thu, 28 Apr 2011 13:30:54 -0700 (PDT) Sender: akarasulu@gmail.com Received: by 10.216.237.142 with HTTP; Thu, 28 Apr 2011 13:30:54 -0700 (PDT) In-Reply-To: References: <4DB94AA0.5030302@gmail.com> <4F5C26AF-2E6A-442C-A694-097C3851A62B@marcelot.net> <4DB97238.4060909@gmail.com> <4DB97E10.9040701@apache.org> <4DB98A21.4010500@gmail.com> <4DB9924A.8090406@gmail.com> Date: Thu, 28 Apr 2011 23:30:54 +0300 X-Google-Sender-Auth: D7Mf9dweRbdD8P-kIEG6_g9QdcE Message-ID: Subject: Re: Search result in LDAP API From: Alex Karasulu To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=000e0cd51aee1d6a3504a2006f7a --000e0cd51aee1d6a3504a2006f7a Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 28, 2011 at 7:28 PM, Stefan Seelmann wrote: > > > > 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 > but > > that the LdapConnection.search( base, filter, scope, attrs... ) returns a > > cursor. > > > > 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? > > This is what I was thinking. More so like a SimpleLdapConnection which can wrap the LowLevelConnection to expose the simple easy to use methods that sit on top of the low level protocol aligned operations. Regards, Alex --000e0cd51aee1d6a3504a2006f7a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 28, 2011 at 7:28 PM, Stefan Seelmann= <seelmann@apac= he.org> wrote:
>
> 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<SearchRespo= nse> but
> that the LdapConnection.search( base, filter, scope, attrs... ) return= s 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<= br> > 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?


This is what I was thinki= ng. More so like a SimpleLdapConnection which can wrap the LowLevelConnecti= on to expose the simple easy to use methods that sit on top of the low leve= l protocol aligned operations.

Regards,
Alex
=A0
--000e0cd51aee1d6a3504a2006f7a--