Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 90075 invoked from network); 23 May 2007 21:14:38 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 23 May 2007 21:14:38 -0000 Received: (qmail 71120 invoked by uid 500); 23 May 2007 21:14:44 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 70896 invoked by uid 500); 23 May 2007 21:14:43 -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 70885 invoked by uid 99); 23 May 2007 21:14:43 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 May 2007 14:14:43 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of ole.ersoy@gmail.com designates 64.233.162.228 as permitted sender) Received: from [64.233.162.228] (HELO nz-out-0506.google.com) (64.233.162.228) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 May 2007 14:14:35 -0700 Received: by nz-out-0506.google.com with SMTP id x3so339068nzd for ; Wed, 23 May 2007 14:14:15 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=fGb9EfmdTFDa+z2UufjrORBP2AQIaRpBMmnVg4LbhWpFRCk2NzmMWMA4WA508DbzOYMnj1u5OTzaFgKdo4Qmyoj2HdrDqvVrF9z0xtZ5GZxcsLml3jMbPqxDzdx3dch9oyZbRgm70BJ8EMMA3IfwrD78AHazAbAjxPJse6XmfWg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ixtVs0WXCrIE36gRGnxFj9/P62eL8rnHQ6Ky76UPhUDMsaYCwXBXaoUZlU293pr+Sq7Be6dHMeflEDqddE+aTwyVgggvccFDjhU+Bu0AAouxW9UKAqnDBa9nRy+PeTKS4wnrKCcp8gN0pnh6ceS/ndUE1l11GOodemXp8+TRiQQ= Received: by 10.65.141.18 with SMTP id t18mr2131882qbn.1179954854901; Wed, 23 May 2007 14:14:14 -0700 (PDT) Received: from ?192.168.1.4? ( [24.13.179.233]) by mx.google.com with ESMTP id 34sm4313346nza.2007.05.23.14.14.14; Wed, 23 May 2007 14:14:14 -0700 (PDT) Message-ID: <4654AD6F.4090609@gmail.com> Date: Wed, 23 May 2007 16:09:03 -0500 From: Ole Ersoy User-Agent: Thunderbird 1.5.0.10 (X11/20070302) MIME-Version: 1.0 To: Apache Directory Developers List Subject: Re: [jira] Created: (DIRSTUDIO-109) Schema Entry Deletes Must be Sequenced References: <27322535.1179947956334.JavaMail.jira@brutus> <46549D6C.5000608@gmail.com> <4654A71F.5090108@apache.org> In-Reply-To: <4654A71F.5090108@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Stefan Seelmann wrote: > Ole, > > I don't think it makes sense to add such semantics into the default > delete operation of the browser. Sure. The use case for me anyways is just to be able to quickly delete some schema containers while debugging junit tests...and I understand that there are probably cross LDAP server considerations, etc... which makes bloating the delete function less sexy... > What we could do is the following: PAM and I would like to extend the > current Schemas Editor to operate directly on the schema partition of > ADS instead of .schema files. So we have to add this functionality into > the Schemas Editor: > > - When saving a new schema into the schema partition we have to consider > the correct order (syntaxes before matching rules before attribute types > before object classes) > > - When deleting a schema we have to consider the inverse order > > Sounds good? Smoookkin!! U and PAM Da Mans! Should I just close this then like Alex recommended? Oh - Incidentally this thought just popped in. Suppose I was editing the Schema partition entries through the browser, like I was doing. Once the Schemas editor connects directly to ADS, might it make sense to "Switch" the delete action to the one used by the Schemas Editor, when connecting to the schema through the browser? Thus the delete action implementation being used would depend on whether the partition being connected to is ADS's schema partition. I need to review the IAdaptable pattern the Eclipse APIs use, but I think that if the action were an IAdaptable then selecting the implementation for the delete action could made fairly elegant. So if ou=schema is the partition, then the cascading delete stuff becomes possible by delegating the delete action request to the CasacdingDelete action, but for all other partitions and connections it's the other delete action implementation. This might provide for a better ADS dynamic schema editing experience. Now it's sort of like this same feature request again :-) Anyways it might be a feature suggestion that could just hang around on in the periphery of LS feature requests, and then if for some reason others start requesting a pluggable/switchable action API in LS, then then maybe it gets interesting. Or we could just nuke it:-) I have both keys. Just give me the signal Cheers, - Ole SNIP