From dev-return-32768-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Mon Mar 01 08:30:00 2010 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 79114 invoked from network); 1 Mar 2010 08:30:00 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Mar 2010 08:30:00 -0000 Received: (qmail 25722 invoked by uid 500); 28 Feb 2010 23:30:01 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 25683 invoked by uid 500); 28 Feb 2010 23:30:01 -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 25669 invoked by uid 99); 28 Feb 2010 23:30:01 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 28 Feb 2010 23:30:01 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of elecharny@gmail.com designates 209.85.219.221 as permitted sender) Received: from [209.85.219.221] (HELO mail-ew0-f221.google.com) (209.85.219.221) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 28 Feb 2010 23:29:52 +0000 Received: by ewy21 with SMTP id 21so1096571ewy.25 for ; Sun, 28 Feb 2010 15:29:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=Wkk8nXHZ9tME7z7j0UBAIYXNcR/CBS+KKkV+t8+mgvw=; b=ASBkMmFgae8tsxLpj4i/heezC7kqYPJLF8RQDH3KiVuC+m1dTzIc1BTKzHVEiqtXlj MSXJinlh4/Q2GH29WTev7CWsZauhAYrdP+Z/8j+N4hl7rFQj7L7goIObSE+re9jwuuoT nPjeBRG7fbJCM1z/G+RvyYmQ6tAG4wWyjxKww= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=l/SJCdoYXi2/nNqjxcCe5vD4mjgd/12P39YK/SGH2pbzOUQZ8zL0gOh9z4fa0UAWuW 8SLA2RhJA9DpWGGuVmuJdQb/gmJcRNgCsXpSJjGUMxPKkxL3UxUyfJOjUwaeHb6N2PuN RlmRdcx5EweGAVXm44l7pB/KbjOVG9F9qQPHk= Received: by 10.213.48.5 with SMTP id p5mr2694241ebf.53.1267399771216; Sun, 28 Feb 2010 15:29:31 -0800 (PST) Received: from emmanuel-lecharnys-MacBook-Pro.local (vol75-3-82-66-216-176.fbx.proxad.net [82.66.216.176]) by mx.google.com with ESMTPS id 28sm905499eyg.38.2010.02.28.15.29.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 28 Feb 2010 15:29:30 -0800 (PST) Message-ID: <4B8AFC59.3050007@gmail.com> Date: Mon, 01 Mar 2010 00:29:29 +0100 From: Emmanuel Lecharny Reply-To: elecharny@apache.org User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: Apache Directory Developers List Subject: Search, list and lookup semantic. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi guys, as I'm trying to remove the JNDI SearchControls from our server, I found three different methods that do a search in the server : - search - lookup - list All those three operations semantic is not exactly clear to me. Let's try to see if they are all useful, and what the semantic is or should be for each of those operations. 1) lookup : The javadoc says : "Looks up an entry in the server returning all attributes: both user and operational attributes.". In fact, we can define the list of Attributes to return. What is not clear is that we don't know if the lookup is done with a ONE_LEVEL scope, or a SUBTREE scope. There is also a difference with JNDI lookup operation that returns a Java instance. IMO, we should drop the JNDI semantic completely (the returned value should be an Entry, not a Java instance), and the scope should be SUBTREE. This resolve to a search with ALIAS_DEREF_ALWAYS, scope SUBTREE, filter (ObjectClass=*), size and time limit set to infinite, no controls, typesOnly set to false. 2) list : The javadoc says : "An optimized search operation using one level search scope which applies size and time limit constraints and returns all the children of an entry specified by distinguished name if these limits are not violated" This is easily replaced by a plain search. I think we can get rid of these methods, which are anyway used only in two places. 3) search : the base method for all the searches. We have a few overloaded methods for search : - search( SearchRequest ) : The base method. Takes all the needed information directly from a request. - search( DN, Filter ) : This is a common one. The question is to determinate which are the dfault values for the scope and alias deref parameters. I suggest SUBTREE and DEREF_ALWAYS. Time and size limits are set to infinite (0), we don't have any controls, and no returning types. All the values are returned. - search( DN, filter, scope ) : same, but the scope is defined. - search( DN, filter, scope, String... attributes ) : The last one with many parameters. In this case, we list all of attributes to return. - search( DN, filter, SearchParams ): In this case, we use another object to store all the parameters we want to use less frequently : time limit, size limit, types only, Alias deref, and controls. I think we should be able to manage all what we want with those operations. wdyt ? -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com