From peterbradley@example.com Wed Feb 03 11:52:31 2010 Return-Path: <peterbradley@example.com> Delivered-To: peterbradley@example.com Received: (qmail 86995 invoked from network); 3 Feb 2010 11:52:31 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 3 Feb 2010 11:52:31 -0000 Received: (qmail 68178 invoked by uid 500); 3 Feb 2010 11:52:31 -0000 Delivered-To: peterbradley@example.com Received: (qmail 68151 invoked by uid 500); 3 Feb 2010 11:52:31 -0000 Mailing-List: contact peterbradley@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:peterbradley@example.com> List-Unsubscribe: <mailto:peterbradley@example.com> List-Post: <mailto:peterbradley@example.com> List-Id: <api.directory.apache.org> Reply-To: peterbradley@example.com Delivered-To: mailing list peterbradley@example.com Received: (qmail 68141 invoked by uid 99); 3 Feb 2010 11:52:30 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Feb 2010 11:52:30 +0000 X-ASF-Spam-Status: No, hits=2.0 required=10.0 tests=RCVD_IN_BL_SPAMCOP_NET,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of peterbradley@example.com designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO mail-px0-f194.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Feb 2010 11:52:21 +0000 Received: by pxi32 with SMTP id 32so1231254pxi.15 for <peterbradley@example.com>; Wed, 03 Feb 2010 03:52:00 -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 :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=Pen4EEMcWiQHpygFiYhfyt8w2ULsToBkdMOZfn3+iac=; b=oR4v3LD2FTwkkPFEGhNG71Tyi4lcJxJaYMkO97f7/xEmyIGgQ5YWvxeJUuDoG78wOw yIQ7La4MYOdJvEEGKplw+q2AWNjpiBjEKtlk1JUHtNg0nE7ZG9iY+IcuKTUAD45nGylD BeE+VYncxpyRjutKTazIP+rtN30SCtVg+2U4w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=XggF/+kW6in07NP/FJlWh2UOyL+qLPUdH6JbaHTyd5I5I7q3KzfrNaZB2YXQrv0U5n GlEjkxZU+K1tL3zVu6LMrKA71JgZpDfxTLx2BMCpUgbrBO6cv56me0bza/Ha+UKbbiHo 2SLTsf5Rstc52c+vwnhRS8wRoFcJDz17bHCGY= Received: by 83.161.120.155 with SMTP id h13mr3944614wal.173.1265197919974; Wed, 03 Feb 2010 03:51:59 -0800 (PST) Received: from ?83.161.120.155? ([83.161.120.155]) by mx.google.com with ESMTPS id 22sm2470089pzk.10.283.161.120.155.51.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Feb 2010 03:51:59 -0800 (PST) Message-ID: <peterbradley@example.com> Date: Wed, 03 Feb 2010 17:21:44 +0530 From: Kiran Ayyagari <peterbradley@example.com> User-Agent: Thunderbird 83.161.120.155 (X11/20090817) MIME-Version: 1.0 To: peterbradley@example.com Subject: making client schema aware Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org hi guys, To make the client aware of schema we need to load it in one of the two ways mentioned below 1. load the schema from the server if the server exposes it 2. have a common set of schema elements bundled with client Do you see any other ways to make the client schema aware? What schemas should be loaded by default? Kiran Ayyagari From peterbradley@example.com Wed Feb 03 12:03:35 2010 Return-Path: <peterbradley@example.com> Delivered-To: peterbradley@example.com Received: (qmail 89823 invoked from network); 3 Feb 2010 12:03:35 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 3 Feb 2010 12:03:35 -0000 Received: (qmail 80999 invoked by uid 500); 3 Feb 2010 12:03:35 -0000 Delivered-To: peterbradley@example.com Received: (qmail 80976 invoked by uid 500); 3 Feb 2010 12:03:35 -0000 Mailing-List: contact peterbradley@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:peterbradley@example.com> List-Unsubscribe: <mailto:peterbradley@example.com> List-Post: <mailto:peterbradley@example.com> List-Id: <api.directory.apache.org> Reply-To: peterbradley@example.com Delivered-To: mailing list peterbradley@example.com Received: (qmail 80965 invoked by uid 99); 3 Feb 2010 12:03:35 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Feb 2010 12:03:35 +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 peterbradley@example.com designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO ey-out-2122.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Feb 2010 12:03:27 +0000 Received: by ey-out-2122.google.com with SMTP id 22so271215eye.9 for <peterbradley@example.com>; Wed, 03 Feb 2010 04:03:06 -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 :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=xlSM/YikdVBUb/2ajQ2MCP0vCFgXjIlAKXRXQu6MoLI=; b=l2GQPEqf4ptkTzinHDUlDhV5P6+mjmAVhcqCkxv5B+TnYU5KVNXPRZEBnpb72dEDfT 2EnJmK/yPm9zfEaF/UaamGGGkkfS9A6Usyh9AgD24DpZT8FHDPsepMzCnGtIkJHU0Aby pVjQtasmLh/MykytXdgqWQ9L6aOD8qAtHMiYY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=O5PI8e5hil03czzVZXKOF8i5kz6KNxEGdYdurYYXsBiDdoa30u801SfnFWvIjZCyEO Fg4yOqoToIFn0/SfXEqvo/SY/G+5DJanLutqiAQXSG3g+jNW2kehszAa4jpV8po18vuS kK4llGxWfWzNjtjXMFNF2zBb4FPA3w2UwecHY= Received: by 83.161.120.155 with SMTP id n29mr848065ebo.6.1265198585989; Wed, 03 Feb 2010 04:03:05 -0800 (PST) Received: from emmanuel-lecharnys-MacBook-Pro.local (vol75-3-82-66-216-176.fbx.proxad.net [83.161.120.155]) by mx.google.com with ESMTPS id 13sm5337206ewy.13.283.161.120.155.03.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Feb 2010 04:03:03 -0800 (PST) Message-ID: <peterbradley@example.com> Date: Wed, 03 Feb 2010 13:03:03 +0100 From: =?UTF-8?B?RW1tYW51ZWwgTMKOY2hhcm55?= <peterbradley@example.com> User-Agent: Thunderbird 83.161.120.155 (Macintosh/20090812) MIME-Version: 1.0 To: peterbradley@example.com Subject: Re: making client schema aware References: <peterbradley@example.com> In-Reply-To: <peterbradley@example.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Kiran Ayyagari a écrit : > hi guys, > > To make the client aware of schema we need to load it in one of the > two ways > mentioned below > > 1. load the schema from the server if the server exposes it > 2. have a common set of schema elements bundled with client > > Do you see any other ways to make the client schema aware? > What schemas should be loaded by default? some thoughts : - we have discussed this extensively in Portland last year with Ludovic, and we aggreed that the API must be schema aware - we must provide a common set of schema (probably core, cosine, system and inetorgperson is the absolute minimum subset) - it should be possible for the user to request that the schema is loaded from the server - it should be possible to create a connection with a reference to the loaded schema - I don't think it's a good idea to request the server for the schema when creating a connection. Either teh schema already exists, or no. If not we use the default schema. - the user should be allowed to extend the schema with his own schema elements - I suggest that the format for such schema extensio to be the OpenLDAP schema format, as it's concise enough > > Kiran Ayyagari > From peterbradley@example.com Wed Feb 03 12:09:05 2010 Return-Path: <peterbradley@example.com> Delivered-To: peterbradley@example.com Received: (qmail 91258 invoked from network); 3 Feb 2010 12:09:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 3 Feb 2010 12:09:05 -0000 Received: (qmail 90167 invoked by uid 500); 3 Feb 2010 12:09:05 -0000 Delivered-To: peterbradley@example.com Received: (qmail 90139 invoked by uid 500); 3 Feb 2010 12:09:05 -0000 Mailing-List: contact peterbradley@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:peterbradley@example.com> List-Unsubscribe: <mailto:peterbradley@example.com> List-Post: <mailto:peterbradley@example.com> List-Id: <api.directory.apache.org> Reply-To: peterbradley@example.com Delivered-To: mailing list peterbradley@example.com Received: (qmail 90129 invoked by uid 99); 3 Feb 2010 12:09:05 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Feb 2010 12:09:05 +0000 X-ASF-Spam-Status: No, hits=-1.8 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [83.161.120.155] (HELO gmp-eb-inf-2.sun.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Feb 2010 12:08:53 +0000 Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [83.161.120.155] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o13C8Ws2000635 for <peterbradley@example.com>; Wed, 3 Feb 2010 12:08:32 GMT MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_2aIJg80ojDan6gIUlBmmkA)" Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <peterbradley@example.com> for peterbradley@example.com; Wed, 03 Feb 2010 12:08:12 +0000 (GMT) Received: from dhcp-egnb07-211-59.france.sun.com ([unknown] [83.161.120.155]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <peterbradley@example.com> for peterbradley@example.com; Wed, 03 Feb 2010 12:08:02 +0000 (GMT) Date: Wed, 03 Feb 2010 13:08:01 +0100 From: Ludovic Poitou <peterbradley@example.com> Subject: Re: making client schema aware In-reply-to: <peterbradley@example.com> Sender: peterbradley@example.com To: peterbradley@example.com Message-id: <peterbradley@example.com> X-Mailer: Apple Mail (2.1077) References: <peterbradley@example.com> X-Virus-Checked: Checked by ClamAV on apache.org --Boundary_(ID_2aIJg80ojDan6gIUlBmmkA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi Kiran, In OpenDS SDK, we have 3 ways for making schema aware clients. - There is a default core schema defined in the SDK. This includes standard LDAP syntaxes, matchingrules, attributetypes and objectclasses (rfc4512) + rfc3045, rfc3112, rfc4519, rfc4530 + very few Sun specific like an approximatematchingrule and password related syntax/MR. - The schema can be loaded/extended from LDIF file - The schema can be loaded from a server. Ludo On Feb 3, 2010, at 12:51 PM, Kiran Ayyagari wrote: > hi guys, > > To make the client aware of schema we need to load it in one of the two ways > mentioned below > > 1. load the schema from the server if the server exposes it > 2. have a common set of schema elements bundled with client > > Do you see any other ways to make the client schema aware? > What schemas should be loaded by default? > > Kiran Ayyagari --- Ludovic Poitou Sun Microsystems Inc. OpenDS Community Manager Directory Services http://blogs.sun.com/Ludo/ Grenoble Engineering Center - France Join OpenDS, https://opends.dev.java.net/servlets/ProjectMembershipRequest Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --Boundary_(ID_2aIJg80ojDan6gIUlBmmkA)-- From peterbradley@example.com Wed Feb 03 12:30:35 2010 Return-Path: <peterbradley@example.com> Delivered-To: peterbradley@example.com Received: (qmail 95359 invoked from network); 3 Feb 2010 12:30:35 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 3 Feb 2010 12:30:35 -0000 Received: (qmail 13190 invoked by uid 500); 3 Feb 2010 12:30:35 -0000 Delivered-To: peterbradley@example.com Received: (qmail 13166 invoked by uid 500); 3 Feb 2010 12:30:35 -0000 Mailing-List: contact peterbradley@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:peterbradley@example.com> List-Unsubscribe: <mailto:peterbradley@example.com> List-Post: <mailto:peterbradley@example.com> List-Id: <api.directory.apache.org> Reply-To: peterbradley@example.com Delivered-To: mailing list peterbradley@example.com Received: (qmail 13156 invoked by uid 99); 3 Feb 2010 12:30:35 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Feb 2010 12:30:35 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of peterbradley@example.com designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO mail-ew0-f218.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Feb 2010 12:30:25 +0000 Received: by ewy10 with SMTP id 10so926527ewy.11 for <peterbradley@example.com>; Wed, 03 Feb 2010 04:30:05 -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 :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=sybnxQGxK2OtbbwjsfZrGvUCW4roUuLi0XJRkgfM63E=; b=bRzN5gwmKTd1UUCSc5FEa3COagYCwopRyIT/AzlDzStZsWlH97l5RPHPElT7dw04m2 G60u2vsP/dIrLVdHUAY/Z+b3mxpHHVVtvDG8yHUh5eDhKNmSxdzO6IZVvpiJoQdW1rWM KLIsXH27U0YGl8VpoEjyycsiHZyu/2mYF8oo0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=fxIyIiBcFOkK0cG8Od85CWQ3a7V10IPvL1Usj07aB4W20qHu+t8znKK+TSuoDOnijX DKHIwGEsoBXWXYcm8/LsvxHc3CvnOyjlaYFk83cYjfSr2fT217WjUsENxP06oLFJAirV N/V+Spmfa5D4qSk90RGQp26f6oKz0wU7bRX5c= Received: by 83.161.120.155 with SMTP id i29mr7173789ebn.99.1265200204469; Wed, 03 Feb 2010 04:30:04 -0800 (PST) Received: from emmanuel-lecharnys-MacBook-Pro.local (vol75-3-82-66-216-176.fbx.proxad.net [83.161.120.155]) by mx.google.com with ESMTPS id 15sm5343183ewy.0.283.161.120.155.30.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Feb 2010 04:30:02 -0800 (PST) Message-ID: <peterbradley@example.com> Date: Wed, 03 Feb 2010 13:30:01 +0100 From: =?UTF-8?B?RW1tYW51ZWwgTMKOY2hhcm55?= <peterbradley@example.com> User-Agent: Thunderbird 83.161.120.155 (Macintosh/20090812) MIME-Version: 1.0 To: peterbradley@example.com Subject: Re: making client schema aware References: <peterbradley@example.com> <peterbradley@example.com> In-Reply-To: <peterbradley@example.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Ludovic Poitou a écrit : > Hi Kiran, > > In OpenDS SDK, we have 3 ways for making schema aware clients. > > - There is a default core schema defined in the SDK. This includes standard LDAP syntaxes, matchingrules, attributetypes and objectclasses (rfc4512) + rfc3045, rfc3112, rfc4519, rfc4530 + very few Sun specific like an approximatematchingrule and password related syntax/MR. > Ca we put on the wiki all the AT, OC, S and MR we are using, with a description of the OpenDS specific ones ? I will create a page where I will push all the basic schema we use and OpenLDAP uses for that purpose. > - The schema can be loaded/extended from LDIF file > Do you have the format you are using ? From peterbradley@example.com Wed Feb 03 15:51:03 2010 Return-Path: <peterbradley@example.com> Delivered-To: peterbradley@example.com Received: (qmail 82179 invoked from network); 3 Feb 2010 15:51:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 3 Feb 2010 15:51:02 -0000 Received: (qmail 93435 invoked by uid 500); 3 Feb 2010 15:51:02 -0000 Delivered-To: peterbradley@example.com Received: (qmail 93409 invoked by uid 500); 3 Feb 2010 15:51:02 -0000 Mailing-List: contact peterbradley@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:peterbradley@example.com> List-Unsubscribe: <mailto:peterbradley@example.com> List-Post: <mailto:peterbradley@example.com> List-Id: <api.directory.apache.org> Reply-To: peterbradley@example.com Delivered-To: mailing list peterbradley@example.com Received: (qmail 93399 invoked by uid 99); 3 Feb 2010 15:51:02 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Feb 2010 15:51:02 +0000 X-ASF-Spam-Status: No, hits=-4.0 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [83.161.120.155] (HELO gmp-eb-inf-1.sun.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 03 Feb 2010 15:50:52 +0000 Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [83.161.120.155] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o13FoUJJ003397 for <peterbradley@example.com>; Wed, 3 Feb 2010 15:50:30 GMT MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; format=flowed; charset=UTF-8 Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <peterbradley@example.com> for peterbradley@example.com; Wed, 03 Feb 2010 15:50:18 +0000 (GMT) Received: from [83.161.120.155] ([unknown] [83.161.120.155]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <peterbradley@example.com> for peterbradley@example.com; Wed, 03 Feb 2010 15:50:06 +0000 (GMT) Date: Wed, 03 Feb 2010 16:50:05 +0100 From: Matthew Swift <peterbradley@example.com> Subject: Re: making client schema aware In-reply-to: <peterbradley@example.com> Sender: peterbradley@example.com To: peterbradley@example.com Message-id: <peterbradley@example.com> References: <peterbradley@example.com> <peterbradley@example.com> <peterbradley@example.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:83.161.120.155pre) Gecko/20100131 Lightning/1.0b1 Shredder/3.0.2pre On 03/02/10 13:30, Emmanuel LŽcharny wrote: > [...] >> - The schema can be loaded/extended from LDIF file > Do you have the format you are using ? > The format of our schema files is pretty straightforward: just plain old LDIF. For example: dn: cn=schema objectClass: top objectClass: ldapSubentry objectClass: subschema attributeTypes: ( 83.161.120.155 NAME 'name' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 83.161.120.155.4.1.1483.161.120.155.15{32768} X-ORIGIN 'RFC 4519' ) attributeTypes: ( 83.161.120.155 NAME 'distinguishedName' EQUALITY distinguishedNameMatch SYNTAX 83.161.120.155.4.1.1483.161.120.155.12 X-ORIGIN 'RFC 4519' ) ... So it is possible to import OpenDS schema using an LDIF reader. Via this mechanism we support loading of all schema elements with the exception of those that require implementation code. Specifically, matching rules are not loaded this way nor are most* syntaxes - instead these are defined in the server configuration together with a reference to the Java class implementing rule/syntax functionality. We then expose the schema to clients via a single cn=schema entry which includes all the loaded schema elements as well as virtual attributes for the syntaxes and matching rules. Matt * it is possible to define new syntaxes via the schema using the schema extensions (meta-syntaxes) that Ludo presented at LDAPcon https://www.opends.org/wiki/page/SubstitutionSyntax https://www.opends.org/wiki/page/EnumerationSyntax https://www.opends.org/wiki/page/RegexSyntax http://blogs.sun.com/Ludo/entry/regular_expression_based_attributes_in http://blogs.sun.com/Ludo/entry/enumeration_based_attributes_in_ldap From peterbradley@example.com Thu Feb 04 15:43:31 2010 Return-Path: <peterbradley@example.com> Delivered-To: peterbradley@example.com Received: (qmail 63994 invoked from network); 4 Feb 2010 15:43:31 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 4 Feb 2010 15:43:31 -0000 Received: (qmail 20567 invoked by uid 500); 4 Feb 2010 15:43:31 -0000 Delivered-To: peterbradley@example.com Received: (qmail 20545 invoked by uid 500); 4 Feb 2010 15:43:31 -0000 Mailing-List: contact peterbradley@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:peterbradley@example.com> List-Unsubscribe: <mailto:peterbradley@example.com> List-Post: <mailto:peterbradley@example.com> List-Id: <api.directory.apache.org> Reply-To: peterbradley@example.com Delivered-To: mailing list peterbradley@example.com Received: (qmail 20528 invoked by uid 99); 4 Feb 2010 15:43:31 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Feb 2010 15:43:31 +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 peterbradley@example.com designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO mail-ew0-f218.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Feb 2010 15:43:22 +0000 Received: by ewy10 with SMTP id 10so797496ewy.11 for <peterbradley@example.com>; Thu, 04 Feb 2010 07:43:00 -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=KcJJ0W1MqRyDxfy700TqZORpEAMVUFCVH+Od/Ms+cIw=; b=TRzpv3buJKs6K5pdlZNljmbO5RCcJIlsc4tL6Roy8ino9bEuk1Mg9kkuHHHkYod957 3zcqAed7bfQFlr90Ey/+ZhfrkokL7SS0Dz+zl8s4wlUKjgxdojLLw0zgTEOwTmz9nQCH adQhY8kj6fJcn0bnrPrUruU9f4+9MnyzWqjJc= 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=SM8aOw7zJHvfzdN0KkA47bgi+ipZgE1rcZec4fbQkNeBd/gDMmAzUSLN8/KJKsnAg8 4iCAu9w2+NwbsMc+WXnyb7KyrKk1mpQc3/V330/uRZ5Gcwk/14ajJx0J6v4aidW0UnX7 Ya0oRTblDsK6GYL/uc39cmB59ExFcPTLdmRQs= Received: by 83.161.120.155 with SMTP id s14mr1141173ebb.77.1265298180655; Thu, 04 Feb 2010 07:43:00 -0800 (PST) Received: from emmanuel-lecharnys-MacBook-Pro.local (lon92-10-78-226-4-211.fbx.proxad.net [83.161.120.155]) by mx.google.com with ESMTPS id 28sm2255056eye.15.283.161.120.155.42.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Feb 2010 07:42:57 -0800 (PST) Message-ID: <peterbradley@example.com> Date: Thu, 04 Feb 2010 16:42:53 +0100 From: Emmanuel Lecharny <peterbradley@example.com> Reply-To: peterbradley@example.com User-Agent: Thunderbird 83.161.120.155 (Macintosh/20090812) MIME-Version: 1.0 To: peterbradley@example.com Subject: About Delete operation Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, LDAP protocol does not allow someone to delete a full tree with a delete operation. Microsoft added a control (1.2.840.113583.161.120.1555 - subtree delete) to provide such a feature. ADS and OpenDS both support it. My question is : should we have a specific deleteTree() method in the API, or should we expect the user to add the subtreeDelete control to a standard DeleteRequest in order to do the same thing ? Right now, we have implemented a programmatic approach of the subtree delete operation this way : - if the server supports the subtree delete control, then send the del request with this control - else recursively delete all the children This is a very costly approach, as there is no way to be sure that an entry is a leaf or has some children but reading the entry (or trying to delete each entry, and if unsuccessful, consider that the entry has children, and recurse). An alternative would be to either use the Control if the server support it, or to throw an excpetion if it does not. wdyt ? -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com From peterbradley@example.com Thu Feb 04 16:33:03 2010 Return-Path: <peterbradley@example.com> Delivered-To: peterbradley@example.com Received: (qmail 80918 invoked from network); 4 Feb 2010 16:33:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 4 Feb 2010 16:33:03 -0000 Received: (qmail 31972 invoked by uid 500); 4 Feb 2010 16:33:03 -0000 Delivered-To: peterbradley@example.com Received: (qmail 31947 invoked by uid 500); 4 Feb 2010 16:33:03 -0000 Mailing-List: contact peterbradley@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:peterbradley@example.com> List-Unsubscribe: <mailto:peterbradley@example.com> List-Post: <mailto:peterbradley@example.com> List-Id: <api.directory.apache.org> Reply-To: peterbradley@example.com Delivered-To: mailing list peterbradley@example.com Received: (qmail 31936 invoked by uid 99); 4 Feb 2010 16:33:02 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Feb 2010 16:33:02 +0000 X-ASF-Spam-Status: No, hits=-1.8 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [83.161.120.155] (HELO gmp-eb-inf-2.sun.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Feb 2010 16:32:52 +0000 Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [83.161.120.155] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o14GWUOb028106 for <peterbradley@example.com>; Thu, 4 Feb 2010 16:32:30 GMT MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_gD5703euuEEUE+UviSfMtw)" Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <peterbradley@example.com> for peterbradley@example.com; Thu, 04 Feb 2010 16:32:24 +0000 (GMT) Received: from dhcp-egnb07-211-59.france.sun.com ([unknown] [83.161.120.155]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <peterbradley@example.com> for peterbradley@example.com; Thu, 04 Feb 2010 16:32:17 +0000 (GMT) Date: Thu, 04 Feb 2010 17:32:15 +0100 From: Ludovic Poitou <peterbradley@example.com> Subject: Re: About Delete operation In-reply-to: <peterbradley@example.com> Sender: peterbradley@example.com To: peterbradley@example.com Message-id: <peterbradley@example.com> X-Mailer: Apple Mail (2.1077) References: <peterbradley@example.com> --Boundary_(ID_gD5703euuEEUE+UviSfMtw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: QUOTED-PRINTABLE On Feb 4, 2010, at 4:42 PM, Emmanuel Lecharny wrote: > Hi, >=20 > LDAP protocol does not allow someone to delete a full tree with a d= elete > operation. Microsoft added a control (1.2.840.113583.161.120.1555 - subt= ree > delete) to provide such a feature. ADS and OpenDS both support it. >=20 > My question is : should we have a specific deleteTree() method in t= he > API, or should we expect the user to add the subtreeDelete control = to a > standard DeleteRequest in order to do the same thing ? I don't think we want to encourage people to use the tree delete oper= ation. It is dangerous and is often restricted to very specific accounts. So I don't think it is important to have a deleteTree method. Even mo= re, I think it's preferable not to have one. >=20 > Right now, we have implemented a programmatic approach of the subtr= ee > delete operation this way : > - if the server supports the subtree delete control, then send the = del > request with this control > - else recursively delete all the children Are you saying that this is your client side implementation of the de= leteTree() method ? >=20 > This is a very costly approach, as there is no way to be sure that = an > entry is a leaf or has some children but reading the entry (or tryi= ng to > delete each entry, and if unsuccessful, consider that the entry has > children, and recurse). Rather than recursing, you could do a subtree search from the base, r= etrieve only DNs, sort them in reverse order of reception (in OpenDS = and DSEE parents are always returned before children entries) and del= ete them one by one.=20 This is the scripted approach taken by many customers for servers tha= t do not support the control. Ludo >=20 > An alternative would be to either use the Control if the server sup= port > it, or to throw an excpetion if it does not. >=20 > wdyt ? >=20 > --=20 > Regards, > Cordialement, > Emmanuel L=E9charny > www.nextury.com >=20 >=20 >=20 --- Ludovic Poitou Sun Microsystems In= c. OpenDS Community Manager Directory Services =20 http://blogs.sun.com/Ludo/ Grenoble Engineering Center - Fran= ce Join OpenDS, https://opends.dev.java.net/servlets/ProjectMembershipRe= quest Sun Microsystems requires the following notice: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibite= d. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~ --Boundary_(ID_gD5703euuEEUE+UviSfMtw)-- From peterbradley@example.com Thu Feb 04 16:44:59 2010 Return-Path: <peterbradley@example.com> Delivered-To: peterbradley@example.com Received: (qmail 84746 invoked from network); 4 Feb 2010 16:44:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 4 Feb 2010 16:44:59 -0000 Received: (qmail 53371 invoked by uid 500); 4 Feb 2010 16:44:59 -0000 Delivered-To: peterbradley@example.com Received: (qmail 53348 invoked by uid 500); 4 Feb 2010 16:44:59 -0000 Mailing-List: contact peterbradley@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:peterbradley@example.com> List-Unsubscribe: <mailto:peterbradley@example.com> List-Post: <mailto:peterbradley@example.com> List-Id: <api.directory.apache.org> Reply-To: peterbradley@example.com Delivered-To: mailing list peterbradley@example.com Received: (qmail 53338 invoked by uid 99); 4 Feb 2010 16:44:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Feb 2010 16:44:59 +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 peterbradley@example.com designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO mail-ew0-f218.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Feb 2010 16:44:51 +0000 Received: by ewy10 with SMTP id 10so864122ewy.11 for <peterbradley@example.com>; Thu, 04 Feb 2010 08:44:29 -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 :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=hIXlDZzBsBzD/E3QIeUMLQFWOApD3WEwpU9InkmWp0g=; b=Gyxs1Mfe67ZV0KSGpU8/z4Oi/724mJ8rltR+TyHSayHGBsS7BO4x9ZPuV3Uf+G5jbZ WZuiyrEPh277StYY5Oj/K9AFp1llSJeZSke4Z5saCrbj/u0ck5dnTqyn2kGxw01COsMh PaMdvVpGaMy13xgkBJIInsQPCuSqQhH7Eo/TQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=X4dr7hRbEOY9fZUm6UJkaiPbJZIti3f1fhET3j4lbELcheG4yPsqEoygpHMKtKtdwb b15iz4vJFtvGXMxcnaOMzPTq537xo4x1rcH4ibmtrR7HRLYixCOGTIzYC7RASiyyXHY6 DqxfHy/3qxr7FNffTv7TBT47o37yc/ADCKFgM= Received: by 83.161.120.155 with SMTP id d10mr3878786ebi.7.1265301864582; Thu, 04 Feb 2010 08:44:24 -0800 (PST) Received: from emmanuel-lecharnys-MacBook-Pro.local (lon92-10-78-226-4-211.fbx.proxad.net [83.161.120.155]) by mx.google.com with ESMTPS id 16sm206666ewy.10.283.161.120.155.44.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Feb 2010 08:44:22 -0800 (PST) Message-ID: <peterbradley@example.com> Date: Thu, 04 Feb 2010 17:44:17 +0100 From: =?UTF-8?B?RW1tYW51ZWwgTMKOY2hhcm55?= <peterbradley@example.com> User-Agent: Thunderbird 83.161.120.155 (Macintosh/20090812) MIME-Version: 1.0 To: peterbradley@example.com Subject: Re: About Delete operation References: <peterbradley@example.com> <peterbradley@example.com> In-Reply-To: <peterbradley@example.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Ludovic Poitou a écrit : > On Feb 4, 2010, at 4:42 PM, Emmanuel Lecharny wrote: > > >> Hi, >> >> LDAP protocol does not allow someone to delete a full tree with a delete >> operation. Microsoft added a control (1.2.840.113583.161.120.1555 - subtree >> delete) to provide such a feature. ADS and OpenDS both support it. >> >> My question is : should we have a specific deleteTree() method in the >> API, or should we expect the user to add the subtreeDelete control to a >> standard DeleteRequest in order to do the same thing ? >> > > I don't think we want to encourage people to use the tree delete operation. > It is dangerous and is often restricted to very specific accounts. > > So I don't think it is important to have a deleteTree method. Even more, I think it's preferable not to have one. > > > >> Right now, we have implemented a programmatic approach of the subtree >> delete operation this way : >> - if the server supports the subtree delete control, then send the del >> request with this control >> - else recursively delete all the children >> > > Are you saying that this is your client side implementation of the deleteTree() method ? > > > >> This is a very costly approach, as there is no way to be sure that an >> entry is a leaf or has some children but reading the entry (or trying to >> delete each entry, and if unsuccessful, consider that the entry has >> children, and recurse). >> > > Rather than recursing, you could do a subtree search from the base, retrieve only DNs, sort them in reverse order of reception (in OpenDS and DSEE parents are always returned before children entries) and delete them one by one. > This is the scripted approach taken by many customers for servers that do not support the control. > I agree. Let's the user send the control if he wants to delete a full tree. From peterbradley@example.com Thu Feb 04 18:39:28 2010 Return-Path: <peterbradley@example.com> Delivered-To: peterbradley@example.com Received: (qmail 43296 invoked from network); 4 Feb 2010 18:39:28 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 4 Feb 2010 18:39:28 -0000 Received: (qmail 27309 invoked by uid 500); 4 Feb 2010 18:39:28 -0000 Delivered-To: peterbradley@example.com Received: (qmail 27286 invoked by uid 500); 4 Feb 2010 18:39:28 -0000 Mailing-List: contact peterbradley@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:peterbradley@example.com> List-Unsubscribe: <mailto:peterbradley@example.com> List-Post: <mailto:peterbradley@example.com> List-Id: <api.directory.apache.org> Reply-To: peterbradley@example.com Delivered-To: mailing list peterbradley@example.com Received: (qmail 27276 invoked by uid 99); 4 Feb 2010 18:39:28 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Feb 2010 18:39:28 +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 peterbradley@example.com designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO ey-out-2122.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Feb 2010 18:39:19 +0000 Received: by ey-out-2122.google.com with SMTP id 4so1486273eyf.1 for <peterbradley@example.com>; Thu, 04 Feb 2010 10:38:58 -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=I/JXwtzGtYfT+jsX6ir4AV4LMt2wDeNV9exGyLQl358=; b=hH3lqNlfYQ00b9BQ4VHs5XM4ex9V7BOBLs9cdeNBHW+9aNr51iNWKEHnK7BGtTvTky q+mRqdNUrqmWPt7z3Y3oSikr/etNuoQHPFA0Qz07APnA8SzWUX7zlo2ARtjTGs6lP75k UyYEd0NeVFYI/ue2QTw4Is0ODjoienoc0JJQg= 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=BWrZDCN31rSThDiPEiil2AfEWMOEEWpd4/m4tTXT1leXanamYaIjVxRIpsEm3Mt2du imdwlP67Qh+vZErU0F8gnUZmrQlXFQIeG3Ldhu8OpbjRKSQHrVdkK9ufI7kX4nRSFIPJ /N9WKg/Ykd21wRhZUJyp9ZBOzdtVubkm5F5M8= Received: by 83.161.120.155 with SMTP id z13mr3813253ebe.56.1265308737466; Thu, 04 Feb 2010 10:38:57 -0800 (PST) Received: from emmanuel-lecharnys-MacBook-Pro.local (lon92-10-78-226-4-211.fbx.proxad.net [83.161.120.155]) by mx.google.com with ESMTPS id 14sm287147ewy.15.283.161.120.155.38.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 04 Feb 2010 10:38:56 -0800 (PST) Message-ID: <peterbradley@example.com> Date: Thu, 04 Feb 2010 19:38:52 +0100 From: Emmanuel Lecharny <peterbradley@example.com> Reply-To: peterbradley@example.com User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:83.161.120.155) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: peterbradley@example.com Subject: Entry API Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi, here are some preliminary thoughts about the Entry class. The Entry class --------------- It's the base data structure representing an element stored into a LDAP server. It has a name (a DN) and some attributes. All the existing API use the same name, Entry (or LDAPEntry), except JNDI which has no such class (it uses Attributes but without a DN) and this class contains at least those two inner elements : - a DN - a set of Attribute There is some difference though as this element is either an Interface (ADS, ODS) or a Class (UID, jLdap) ODS define an implementing class named SortedEntry, which does not make a lot of sense, IMO. ADS class hierarchy is even more complex, as there are two lower interfaces (ClientEntry and ServerEntry) with two implementing classes (DefaultClientEntry and DefaultServerEntry). Overkilling … (and will be rewritten soon) All in all, I'm wondering if it's a good idea to have an interface instead of a class, as it does not make a lot of sense to implement some different version of such an object. Constructors ------------ Here are the current implementations : ADS : DefaultClientEntry() DefaultClientEntry(LdapDN) DefaultClientEntry(LdapDN, EntryAttribute...) DefaultClientEntry(LdapDN, String...) DefaultServerEntry(SchemaManager) DefaultServerEntry(SchemaManager, Entry) DefaultServerEntry(SchemaManager, LdapDN) DefaultServerEntry(SchemaManager, LdapDN, AttributeType, String) DefaultServerEntry(SchemaManager, LdapDN, AttributeType...) DefaultServerEntry(SchemaManager, LdapDN, ServerAttribute...) DefaultServerEntry(SchemaManager, LdapDN, String...) jLdap : LDAPEntry() LDAPEntry(String) LDAPEntry(String, LDAPAttributeSet) JNDI : N/A OpenDS : SortedEntry() SortedEntry(DN) SortedEntry(Entry) SortedEntry(String) SortedEntry(String...) UID : Entry(DN) Entry(DN, Attribute...) Entry(DN, Collection<Attribute>) Entry(String) Entry(String, Attribute...) Entry(String, Collection<Attribute>) Entry(String...) Quite complex :/ The problem here is that we would like those entries to be schema aware. The question is : how to make it simple for the user to create a schema aware entry? Either the entry comes from the server he is connected to, or he creates new entries on the client before sending them to the server. In both cases, the entry has to know about the schema. Let's first assume that it's the case. The minimal list of constructors is : Entry() : an empty constructor Entry(DN) Entry(String) : The DN is a string Entry(DN, Attribute…) Entry(String, Attribute…) Entry(String…) : A special constructor which takes a list of strings representing a LDIF form of the entry All those constructors will assume that the default schema will be used. We can then inject a Schema by adding it to the constructor : Entry(SchemaManager) : an empty constructor Entry(SchemaManager, DN) Entry(SchemaManager, String) : The DN is a string Entry(SchemaManager, DN, Attribute…) Entry(SchemaManager, String, Attribute…) Entry(SchemaManager, String…) : A special constructor which takes a list of strings representing a LDIF form of the entry Thoughts ? -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com From peterbradley@example.com Thu Feb 04 19:54:50 2010 Return-Path: <peterbradley@example.com> Delivered-To: peterbradley@example.com Received: (qmail 60870 invoked from network); 4 Feb 2010 19:54:50 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 4 Feb 2010 19:54:50 -0000 Received: (qmail 24305 invoked by uid 500); 4 Feb 2010 19:54:50 -0000 Delivered-To: peterbradley@example.com Received: (qmail 24283 invoked by uid 500); 4 Feb 2010 19:54:50 -0000 Mailing-List: contact peterbradley@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:peterbradley@example.com> List-Unsubscribe: <mailto:peterbradley@example.com> List-Post: <mailto:peterbradley@example.com> List-Id: <api.directory.apache.org> Reply-To: peterbradley@example.com Delivered-To: mailing list peterbradley@example.com Received: (qmail 24268 invoked by uid 99); 4 Feb 2010 19:54:50 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Feb 2010 19:54:50 +0000 X-ASF-Spam-Status: No, hits=4.7 required=10.0 tests=HTML_MESSAGE,LOCALPART_IN_SUBJECT,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of peterbradley@example.com designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO mail-fx0-f220.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Feb 2010 19:54:42 +0000 Received: by fxm20 with SMTP id 20so2997076fxm.1 for <peterbradley@example.com>; Thu, 04 Feb 2010 11:54:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=Jf9PLtF8h1N1QVrLdg3gSnNqsRFF3vCSB35yRfnBwlc=; b=flebHgf7UL0frw8XubZlW5wqBh4X3JQ3J7/+2+RoOeyuI2GlA6Cg+JhKSXpoxDAP1j x1kS3nJRNuL7OOlArHFHw8g8Ycg2i9m3e2E4xuc0PeaF9G85bFAjj5ULagkUoBSn6Pw9 9iDcLeGvC28i7O+HpMuQ4wg1loCTcLLRT4i84= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=TFdY9sdk8KjWriROSQvtm0g0XRxYIDrjyHSNxupMEJXxoUvrPS7QqpZY9YDox0e1nw OSDAsjGYWm2PpVJiB1S6e9b7LEitStBLZHJZEyNp58iiaZ8xTZkWa+WB40WtDBqIFCDa n0ypaQnArnLFCpTQRkL3FPLQvH7zE5NP302pM= MIME-Version: 1.0 Received: by 83.161.120.155 with SMTP id r7mr162233hbh.116.1265313262161; Thu, 04 Feb 2010 11:54:22 -0800 (PST) In-Reply-To: <peterbradley@example.com> References: <peterbradley@example.com> Date: Thu, 4 Feb 2010 21:54:22 +0200 Message-ID: <peterbradley@example.com> Subject: Re: Entry API From: Alex Karasulu <peterbradley@example.com> To: peterbradley@example.com, peterbradley@example.com Content-Type: multipart/alternative; boundary=001485f727008551c7047ecbb371 X-Virus-Checked: Checked by ClamAV on apache.org --001485f727008551c7047ecbb371 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Thu, Feb 4, 2010 at 8:38 PM, Emmanuel Lecharny <peterbradley@example.com>wrot= e: > Hi, > > here are some preliminary thoughts about the Entry class. > > The Entry class > --------------- > > It's the base data structure representing an element stored into a LDAP > server. It has a name (a DN) and some attributes. > > All the existing API use the same name, Entry (or LDAPEntry), except JNDI > which has no such class (it uses Attributes but without a DN) and this cl= ass > contains at least those two inner elements : > - a DN > - a set of Attribute > > There is some difference though as this element is either an Interface > (ADS, ODS) or a Class (UID, jLdap) > > ODS define an implementing class named SortedEntry, which does not make a > lot of sense, IMO. ADS class hierarchy is even more complex, as there are > two lower interfaces (ClientEntry and ServerEntry) with two implementing > classes (DefaultClientEntry and DefaultServerEntry). Overkilling =85 (and= will > be rewritten soon) > > I'd be careful to remove interfaces. As an API you have to allow the broadest range of implementation possibilities. Interfaces are good to have= . When in doubt keep the interface. All in all, I'm wondering if it's a good idea to have an interface instead > of a class, as it does not make a lot of sense to implement some differen= t > version of such an object. > > It's hard to foresee the future here. You've got to watch out when you're trying to prognosticate the future while designing an API. Just my two cents. Alex --001485f727008551c7047ecbb371-- From peterbradley@example.com Thu Feb 04 20:00:58 2010 Return-Path: <peterbradley@example.com> Delivered-To: peterbradley@example.com Received: (qmail 62790 invoked from network); 4 Feb 2010 20:00:58 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 4 Feb 2010 20:00:58 -0000 Received: (qmail 30369 invoked by uid 500); 4 Feb 2010 20:00:58 -0000 Delivered-To: peterbradley@example.com Received: (qmail 30343 invoked by uid 500); 4 Feb 2010 20:00:58 -0000 Mailing-List: contact peterbradley@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:peterbradley@example.com> List-Unsubscribe: <mailto:peterbradley@example.com> List-Post: <mailto:peterbradley@example.com> List-Id: <api.directory.apache.org> Reply-To: peterbradley@example.com Delivered-To: mailing list peterbradley@example.com Received: (qmail 30333 invoked by uid 99); 4 Feb 2010 20:00:58 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Feb 2010 20:00:58 +0000 X-ASF-Spam-Status: No, hits=-1997.5 required=10.0 tests=ALL_TRUSTED,LOCALPART_IN_SUBJECT X-Spam-Check-By: apache.org Received: from [83.161.120.155] (HELO minotaur.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 04 Feb 2010 20:00:49 +0000 Received: (qmail 62547 invoked by uid 99); 4 Feb 2010 20:00:27 -0000 Received: from localhost.apache.org (HELO emmanuel-lecharnys-MacBook-Pro.local) (83.161.120.155) (smtp-auth username elecharny, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Feb 2010 20:00:27 +0000 Message-ID: <peterbradley@example.com> Date: Thu, 04 Feb 2010 21:00:10 +0100 From: =?windows-1252?Q?Emmanuel_L=E9charny?= <peterbradley@example.com> Reply-To: peterbradley@example.com Organization: The Apache Software Foundation User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:83.161.120.155) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: peterbradley@example.com Subject: Re: Entry API References: <peterbradley@example.com> <peterbradley@example.com> In-Reply-To: <peterbradley@example.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org On 2/4/10 8:54 PM, Alex Karasulu wrote: > On Thu, Feb 4, 2010 at 8:38 PM, Emmanuel Lecharny<peterbradley@example.com>wrote: > > I'd be careful to remove interfaces. As an API you have to allow the > broadest range of implementation possibilities. Interfaces are good to have. > When in doubt keep the interface. > Another possibility (in conjonction with he fact that we might want to have schema aware entries) is to use a factory to build entries, instead of having a constructor. If we have to keep the Interface, what would be the name for the class ? EntryImpl ? DefaultEntry? -- Regards, Cordialement, Emmanuel Lécharny www.nextury.com From peterbradley@example.com Fri Feb 05 02:14:57 2010 Return-Path: <peterbradley@example.com> Delivered-To: peterbradley@example.com Received: (qmail 10144 invoked from network); 5 Feb 2010 02:14:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 5 Feb 2010 02:14:57 -0000 Received: (qmail 95649 invoked by uid 500); 5 Feb 2010 02:14:57 -0000 Delivered-To: peterbradley@example.com Received: (qmail 95627 invoked by uid 500); 5 Feb 2010 02:14:57 -0000 Mailing-List: contact peterbradley@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:peterbradley@example.com> List-Unsubscribe: <mailto:peterbradley@example.com> List-Post: <mailto:peterbradley@example.com> List-Id: <api.directory.apache.org> Reply-To: peterbradley@example.com Delivered-To: mailing list peterbradley@example.com Received: (qmail 95617 invoked by uid 99); 5 Feb 2010 02:14:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Feb 2010 02:14:56 +0000 X-ASF-Spam-Status: No, hits=2.5 required=10.0 tests=LOCALPART_IN_SUBJECT,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of peterbradley@example.com designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO mail-pz0-f201.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Feb 2010 02:14:48 +0000 Received: by pzk39 with SMTP id 39so3344465pzk.15 for <peterbradley@example.com>; Thu, 04 Feb 2010 18:14:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=YNtmyIBiKOa2+EMPncycG0MMUwWkC4xhQvnJgAbNm1w=; b=w0Hhx9vxnBo2AAb+S81hslgBfA+hbxoVAhY0wordhbHMGAV2DJRNq9r5/2GE+Zju8J g/5JvMsohLaoJpCcPLU+efue2lFZE2nYUrixKmKsNKusS/jEY4oLWGBHohYd4s+4wyvL QCXx4XGPjvr2Dpc9op+indzP27TE9cNayOiuM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=BOEN0G320l6UggqDiysDIy3w/d/PLUZ8d8ROsVjFHWSv02WRizurkAtlHpuG2Jdfu3 E1A2F0R7BaNXVIHxOvtZxBmPq+1GHv3JCxi165OGTKftrtfuWZkE2pQNJ8iqSNU+BD7J wrCIEVlH8zVNLChLaHG2saJ5z80uuIg5ctrDA= MIME-Version: 1.0 Received: by 83.161.120.155 with SMTP id q11mr1376811rvi.2.1265336066597; Thu, 04 Feb 2010 18:14:26 -0800 (PST) In-Reply-To: <peterbradley@example.com> References: <peterbradley@example.com> <peterbradley@example.com> <peterbradley@example.com> Date: Fri, 5 Feb 2010 07:44:26 +0530 Message-ID: <peterbradley@example.com> Subject: Re: Entry API From: Kiran Ayyagari <peterbradley@example.com> To: peterbradley@example.com, peterbradley@example.com Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Checked: Checked by ClamAV on apache.org > Another possibility (in conjonction with he fact that we might want to have > schema aware entries) is to use a factory to build entries, instead of > having a constructor. I don't know if the factory is really required here cause what I think of is just a *Entry*. It will be aware of schema if SchemaManager is injected else not (i.e equivalent to DefaultClientEntry) > > If we have to keep the Interface, what would be the name for the class ? > EntryImpl ? DefaultEntry? to me EntryImpl sounds good, cause DefaultEntry gives an impression that there exists another implementation. Kiran Ayyagari From peterbradley@example.com Fri Feb 05 06:31:42 2010 Return-Path: <peterbradley@example.com> Delivered-To: peterbradley@example.com Received: (qmail 83326 invoked from network); 5 Feb 2010 06:31:41 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 5 Feb 2010 06:31:41 -0000 Received: (qmail 37633 invoked by uid 500); 5 Feb 2010 06:31:41 -0000 Delivered-To: peterbradley@example.com Received: (qmail 37605 invoked by uid 500); 5 Feb 2010 06:31:41 -0000 Mailing-List: contact peterbradley@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:peterbradley@example.com> List-Unsubscribe: <mailto:peterbradley@example.com> List-Post: <mailto:peterbradley@example.com> List-Id: <api.directory.apache.org> Reply-To: peterbradley@example.com Delivered-To: mailing list peterbradley@example.com Received: (qmail 37595 invoked by uid 99); 5 Feb 2010 06:31:40 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Feb 2010 06:31:40 +0000 X-ASF-Spam-Status: No, hits=4.7 required=10.0 tests=HTML_MESSAGE,LOCALPART_IN_SUBJECT,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of peterbradley@example.com designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO fg-out-1718.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Feb 2010 06:31:32 +0000 Received: by fg-out-1718.google.com with SMTP id 19so124915fgg.1 for <peterbradley@example.com>; Thu, 04 Feb 2010 22:31:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=xScq/+v+a3vrj+nOOWPAUz/pV7+2CdxThpweVzIh0uQ=; b=bw1zd9lHUS/tUC8RK7/Br8Y4uZEUDYlkM3KyO3iFnVh/lN9VjeXaAbr02QEsBjhHTt Fgv7fXl313VhXjC7FNOoQoSth1z2b66q5tcmO/B/fM2OcIHqMRFBownHykmX+y08KQu3 AFfU3eTpq59zMgluMxXNgOjFKqSMUlbSMJaJY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=BjCJsgqXt3dY9TnMi3GZPmHZHX6riA2XeUGCfYFHuO150GkT+Q98ac/w/XKCJ0RM9w eCHP0LSE8+cFVn2SUiy0Ycwvy0GBscvRv6ix7+zwSu2jX9y07p7RIPUXYVAPflk38C4a ZPeqbI8xsT6HsIyMBY+vK6YKa6qBxxV/jtuzE= MIME-Version: 1.0 Received: by 83.161.120.155 with SMTP id l4mr219221hbh.87.1265351466600; Thu, 04 Feb 2010 22:31:06 -0800 (PST) In-Reply-To: <peterbradley@example.com> References: <peterbradley@example.com> <peterbradley@example.com> <peterbradley@example.com> Date: Fri, 5 Feb 2010 08:31:06 +0200 Message-ID: <peterbradley@example.com> Subject: Re: Entry API From: Alex Karasulu <peterbradley@example.com> To: peterbradley@example.com, peterbradley@example.com Content-Type: multipart/alternative; boundary=001485f91450aecb0a047ed4987e X-Virus-Checked: Checked by ClamAV on apache.org --001485f91450aecb0a047ed4987e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Feb 4, 2010 at 10:00 PM, Emmanuel L=E9charny <peterbradley@example.com>= wrote: > On 2/4/10 8:54 PM, Alex Karasulu wrote: > >> On Thu, Feb 4, 2010 at 8:38 PM, Emmanuel Lecharny<peterbradley@example.com >> >wrote: >> I'd be careful to remove interfaces. As an API you have to allow the >> broadest range of implementation possibilities. Interfaces are good to >> have. >> When in doubt keep the interface. >> >> > > Another possibility (in conjonction with he fact that we might want to ha= ve > schema aware entries) is to use a factory to build entries, instead of > having a constructor. > > If we have to keep the Interface, what would be the name for the class ? > EntryImpl ? DefaultEntry? > > I see what you're getting at. Sometimes I feel like this IEntry for the interface name might be best so there's room to have a simple Entry class a= s the default implementation while still offering an interface to implement for API users. Alex --001485f91450aecb0a047ed4987e-- From peterbradley@example.com Fri Feb 05 10:43:34 2010 Return-Path: <peterbradley@example.com> Delivered-To: peterbradley@example.com Received: (qmail 62515 invoked from network); 5 Feb 2010 10:43:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 5 Feb 2010 10:43:34 -0000 Received: (qmail 28531 invoked by uid 500); 5 Feb 2010 10:43:34 -0000 Delivered-To: peterbradley@example.com Received: (qmail 28505 invoked by uid 500); 5 Feb 2010 10:43:33 -0000 Mailing-List: contact peterbradley@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:peterbradley@example.com> List-Unsubscribe: <mailto:peterbradley@example.com> List-Post: <mailto:peterbradley@example.com> List-Id: <api.directory.apache.org> Reply-To: peterbradley@example.com Delivered-To: mailing list peterbradley@example.com Received: (qmail 28495 invoked by uid 99); 5 Feb 2010 10:43:33 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Feb 2010 10:43:33 +0000 X-ASF-Spam-Status: No, hits=-4.0 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [83.161.120.155] (HELO gmp-eb-inf-2.sun.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Feb 2010 10:43:24 +0000 Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [83.161.120.155] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o15Ah2lT005089 for <peterbradley@example.com>; Fri, 5 Feb 2010 10:43:02 GMT MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; format=flowed; charset=UTF-8 Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <peterbradley@example.com> for peterbradley@example.com; Fri, 05 Feb 2010 10:42:41 +0000 (GMT) Received: from [83.161.120.155] ([unknown] [83.161.120.155]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <peterbradley@example.com> for peterbradley@example.com; Fri, 05 Feb 2010 10:42:32 +0000 (GMT) Date: Fri, 05 Feb 2010 11:42:28 +0100 From: Matthew Swift <peterbradley@example.com> Subject: Re: About Delete operation In-reply-to: <peterbradley@example.com> Sender: peterbradley@example.com To: peterbradley@example.com Message-id: <peterbradley@example.com> References: <peterbradley@example.com> <peterbradley@example.com> <peterbradley@example.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:83.161.120.155pre) Gecko/20100204 Lightning/1.0b1 Shredder/3.0.2pre On 04/02/10 17:44, Emmanuel LŽcharny wrote: > [...] >> Rather than recursing, you could do a subtree search from the base, >> retrieve only DNs, sort them in reverse order of reception (in OpenDS >> and DSEE parents are always returned before children entries) and >> delete them one by one. This is the scripted approach taken by many >> customers for servers that do not support the control. > > > I agree. Let's the user send the control if he wants to delete a full > tree. > +1 Matt From peterbradley@example.com Fri Feb 05 23:35:29 2010 Return-Path: <peterbradley@example.com> Delivered-To: peterbradley@example.com Received: (qmail 59176 invoked from network); 5 Feb 2010 23:35:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 5 Feb 2010 23:35:29 -0000 Received: (qmail 60535 invoked by uid 500); 5 Feb 2010 23:35:29 -0000 Delivered-To: peterbradley@example.com Received: (qmail 60512 invoked by uid 500); 5 Feb 2010 23:35:28 -0000 Mailing-List: contact peterbradley@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:peterbradley@example.com> List-Unsubscribe: <mailto:peterbradley@example.com> List-Post: <mailto:peterbradley@example.com> List-Id: <api.directory.apache.org> Reply-To: peterbradley@example.com Delivered-To: mailing list peterbradley@example.com Received: (qmail 60500 invoked by uid 99); 5 Feb 2010 23:35:28 -0000 Received: from nike.apache.org (HELO nike.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Feb 2010 23:35:28 +0000 X-ASF-Spam-Status: No, hits=-1.5 required=10.0 tests=LOCALPART_IN_SUBJECT,RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [83.161.120.155] (HELO gmp-eb-inf-1.sun.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Feb 2010 23:35:17 +0000 Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [83.161.120.155] (may be forged)) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o15NYu4p021780 for <peterbradley@example.com>; Fri, 5 Feb 2010 23:34:56 GMT MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; format=flowed; charset=windows-1252 Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <peterbradley@example.com> for peterbradley@example.com; Fri, 05 Feb 2010 23:34:42 +0000 (GMT) Received: from [83.161.120.155] ([unknown] [83.161.120.155]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <peterbradley@example.com> for peterbradley@example.com; Fri, 05 Feb 2010 23:34:42 +0000 (GMT) Date: Sat, 06 Feb 2010 00:34:41 +0100 From: Matthew Swift <peterbradley@example.com> Subject: Re: Entry API In-reply-to: <peterbradley@example.com> Sender: peterbradley@example.com To: peterbradley@example.com Message-id: <peterbradley@example.com> References: <peterbradley@example.com> <peterbradley@example.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:83.161.120.155pre) Gecko/20100205 Lightning/1.0b1 Shredder/3.0.2pre X-Virus-Checked: Checked by ClamAV on apache.org I totally agree with Alex. Entry MUST be an interface - I feel very strongly about this :-) In ODS we take the Collections API approach by having Entry defined as an interface and then providing several sub-implementations based on the storage/retrieval model the implementation provides. We only have one implementation so far which is a TreeMap based Entry called SortedEntry (it may have been better to call it TreeMapEntry). This gives nice user-friendly behavior in GUIs for example since our AttributeDescription (the keys in the TreeMap) have a sort order: objectClass first, then user attributes, then operational attributes, each group sorted alphabetically. However, this is not so good in other use cases: * other tools would be better using a LinkedHashMap instead in order to preserve the original ordering * proxy like apps are unlikely to need to query the entry, just reserialize it, so they need an implementation which is tuned for decode/encode * entry caches need an implementation tuned for memory footprint and which is read-only * a tool such as searchrate would need a "null" entry implementation - it throws away any attributes you attempt to store in the entry (typically you don't want a searchrate tool to decode every SearchResultEntry into a TreeMap/LinkHashMap based Entry). That's just a few example use cases and I can think of a few others too. I also agree with the requirement to have an EntryFactory interface. This can be passed to search operations in order to determine which implementation is used. I recently raised these RFEs to the ODS SDK which proves that I am not making this up as I go along: ;-) https://opends.dev.java.net/issues/show_bug.cgi?id=4425 https://opends.dev.java.net/issues/show_bug.cgi?id=4426 As for naming, I am a bit against having a "default implementation" called something like EntryImpl since the name does not communicate anything about how it works (is it sorted, original order, etc?). Regarding schema, I have implemented the following policy in our SDK: * DNs need a schema for decoding * Attribute descriptions need a schema for decoding * Filters need a schema during compilation (out of scope here as this is a server side thing) * Entries need a schema for schema validation * IIRC all other objects in the SDK either do not need schema (e.g. SearchScope) or are containers of some sort containing DNs, attributes, etc (e.g. entries, requests, etc). Containers: o provide methods which accept pre-decoded objects (DN, AttributeDescription, Attribute, etc) which are already associated with a schema o provide ease-of-use String based methods (e.g. Entry.setDN(String)) o have no intrinsic Schema associated with them. Otherwise, consider what it means if an Entry did have an intrinsic Schema - what would happen if I call Entry.setDN(DN) using a DN decoded using a different schema? Should an exception be thrown? o attempts to use String based methods which require some form of decoding (e.g. Entry.setDN(String)) always use the global default schema. I don't know if it makes much sense to you guys - I understand that there is no right or wrong way here. I took this approach after spending many hours (days?) pondering and playing around with alternatives and simply settled on the one above. I figured that if applications are using String based methods then they are probably only using a single default schema. I think that this is a reasonable assumption and avoids potentially confusing APIs and unexpected behaviors. E.g: Schema schema1 = ...; Schema schema2 = ...; DN dn = DN.valueOf(schema1, "dc=example,dc=com"); // Two different schema - what happens here? Entry entry = new LinkedHashMapEntry(schema2, dn); Matt On 04/02/10 20:54, Alex Karasulu wrote: > On Thu, Feb 4, 2010 at 8:38 PM, Emmanuel Lecharny<peterbradley@example.com>wrote: > > >> Hi, >> >> here are some preliminary thoughts about the Entry class. >> >> The Entry class >> --------------- >> >> It's the base data structure representing an element stored into a LDAP >> server. It has a name (a DN) and some attributes. >> >> All the existing API use the same name, Entry (or LDAPEntry), except JNDI >> which has no such class (it uses Attributes but without a DN) and this class >> contains at least those two inner elements : >> - a DN >> - a set of Attribute >> >> There is some difference though as this element is either an Interface >> (ADS, ODS) or a Class (UID, jLdap) >> >> ODS define an implementing class named SortedEntry, which does not make a >> lot of sense, IMO. ADS class hierarchy is even more complex, as there are >> two lower interfaces (ClientEntry and ServerEntry) with two implementing >> classes (DefaultClientEntry and DefaultServerEntry). Overkilling … (and will >> be rewritten soon) >> >> >> > I'd be careful to remove interfaces. As an API you have to allow the > broadest range of implementation possibilities. Interfaces are good to have. > When in doubt keep the interface. > > All in all, I'm wondering if it's a good idea to have an interface instead > >> of a class, as it does not make a lot of sense to implement some different >> version of such an object. >> >> >> > It's hard to foresee the future here. You've got to watch out when you're > trying to prognosticate the future while designing an API. > > Just my two cents. > > Alex > > From peterbradley@example.com Sat Feb 06 11:12:53 2010 Return-Path: <peterbradley@example.com> Delivered-To: peterbradley@example.com Received: (qmail 7559 invoked from network); 6 Feb 2010 11:12:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (83.161.120.155) by minotaur.apache.org with SMTP; 6 Feb 2010 11:12:53 -0000 Received: (qmail 51548 invoked by uid 500); 6 Feb 2010 11:12:53 -0000 Delivered-To: peterbradley@example.com Received: (qmail 51524 invoked by uid 500); 6 Feb 2010 11:12:53 -0000 Mailing-List: contact peterbradley@example.com; run by ezmlm Precedence: bulk List-Help: <mailto:peterbradley@example.com> List-Unsubscribe: <mailto:peterbradley@example.com> List-Post: <mailto:peterbradley@example.com> List-Id: <api.directory.apache.org> Reply-To: peterbradley@example.com Delivered-To: mailing list peterbradley@example.com Received: (qmail 51514 invoked by uid 99); 6 Feb 2010 11:12:52 -0000 Received: from athena.apache.org (HELO athena.apache.org) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 06 Feb 2010 11:12:52 +0000 X-ASF-Spam-Status: No, hits=2.5 required=10.0 tests=LOCALPART_IN_SUBJECT,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of peterbradley@example.com designates 83.161.120.155 as permitted sender) Received: from [83.161.120.155] (HELO ey-out-2122.google.com) (83.161.120.155) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 06 Feb 2010 11:12:43 +0000 Received: by ey-out-2122.google.com with SMTP id 22so975428eye.9 for <peterbradley@example.com>; Sat, 06 Feb 2010 03:12:22 -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:references:in-reply-to :content-type:content-transfer-encoding; bh=l0UQ46LaEkIuAVq3wvdIGgQV3a6bnfGit4PeVeW1Ouc=; b=q8j/6TDjZXG5bn9K7mvgIVdotYH0oVGr0eJ+lIKdJdssZskl0XOGkuhSNxDBjI3r8R E9pYWMIRKGKLN8lg+oIkr9BrhGGhkfGzeYAATvQA4e595suLu5JoFnYEbrLcd6yD+mEY COgGPCJNxa6Q8oSR5Ayvktj0kyBkyau0j/qUM= 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 :references:in-reply-to:content-type:content-transfer-encoding; b=hkg1dnTmLia4JGj/ab7ERBBFfNNrE/FzQw4OyvnZNlY+O6jIU3JIINBVa17Rk2bhl8 bDNYpoDEcgwF4TDT/6Zhq8NAGZmc/4PvTWBK54mcVJsFKsRGF3n+x4PyUN6qnfRDMMTU xyMUlKyqWH0ucVrLKmuPjOmgrLtbZuocZxSu0= Received: by 83.161.120.155 with SMTP id g4mr2000036ebe.33.1265454741880; Sat, 06 Feb 2010 03:12:21 -0800 (PST) Received: from emmanuel-lecharnys-MacBook-Pro.local (vol75-3-82-66-216-176.fbx.proxad.net [83.161.120.155]) by mx.google.com with ESMTPS id 13sm1614570ewy.13.283.161.120.155.12.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 06 Feb 2010 03:12:18 -0800 (PST) Message-ID: <peterbradley@example.com> Date: Sat, 06 Feb 2010 12:12:17 +0100 From: Emmanuel Lecharny <peterbradley@example.com> Reply-To: peterbradley@example.com User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:83.161.120.155) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: peterbradley@example.com Subject: Re: Entry API References: <peterbradley@example.com> <peterbradley@example.com> <peterbradley@example.com> In-Reply-To: <peterbradley@example.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 2/6/10 12:34 AM, Matthew Swift wrote: > I totally agree with Alex. Entry MUST be an interface - I feel very > strongly about this :-) this is probably why ODS and ADS Entry are both interface :) Alex is right here : having it an interface does not obliterate the future. > > In ODS we take the Collections API approach by having Entry defined as > an interface and then providing several sub-implementations based on > the storage/retrieval model the implementation provides. We only have > one implementation so far which is a TreeMap based Entry called > SortedEntry (it may have
{'source': 'Apache Software Foundation Public Mail Archives'}