From dev-return-37860-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Sun Apr 24 10:38:50 2011 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 B2DBC1E6C for ; Sun, 24 Apr 2011 10:38:50 +0000 (UTC) Received: (qmail 54988 invoked by uid 500); 24 Apr 2011 10:38:50 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 54929 invoked by uid 500); 24 Apr 2011 10:38:50 -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 54922 invoked by uid 99); 24 Apr 2011 10:38:50 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 24 Apr 2011 10:38:50 +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 (nike.apache.org: domain of akarasulu@gmail.com designates 74.125.82.44 as permitted sender) Received: from [74.125.82.44] (HELO mail-ww0-f44.google.com) (74.125.82.44) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 24 Apr 2011 10:38:42 +0000 Received: by wwa36 with SMTP id 36so1743283wwa.1 for ; Sun, 24 Apr 2011 03:38:22 -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=PzWypOyPuDOtSXkEYv381eLc2Xs0HgALgtb4KgtHOag=; b=trILzkBhC/bOnztZohmbRWKjcYpczSRNioTEWExXOZu1Jqc7cE8oOB5T9yQr18bILi toKGJYUxY0gVEXlBxLAPsxyUMj89t8Ipj8c6X8hWyGzAoec7v8VOowVV52sRuijX1KW/ kdmqqBs41cndb+Rt84BbDED0O7ckLL/uS4sOU= 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=c3pygDeBUSLlzwBAypwKo3ZUjGz5sUTnpqEhcNtbMtkoyXTbOgUXAupoaiUw+5+7zV eVDhKKhgCbJjq/cH5sntkvi3fyBFwlv87g3/ktb1UVmrkpNu61r845o0c5ZRnjT7WkgU bY21u4uOu+9UbNjwlJ8VEz7RaVzgvveqmrZ0w= MIME-Version: 1.0 Received: by 10.216.69.3 with SMTP id m3mr878302wed.9.1303641501960; Sun, 24 Apr 2011 03:38:21 -0700 (PDT) Sender: akarasulu@gmail.com Received: by 10.216.237.142 with HTTP; Sun, 24 Apr 2011 03:38:21 -0700 (PDT) In-Reply-To: <4DB3F6E1.8030405@apache.org> References: <4DB3ED8D.60903@gmail.com> <4DB3F6E1.8030405@apache.org> Date: Sun, 24 Apr 2011 13:38:21 +0300 X-Google-Sender-Auth: VYRdQC8EOaajYoVkbnhBytaQm8g Message-ID: Subject: Re: Cascade control : is it still usdeful ? From: Alex Karasulu To: Apache Directory Developers List , elecharny@apache.org Content-Type: multipart/alternative; boundary=000e0ce0b4dca38c1004a1a7b0fe X-Virus-Checked: Checked by ClamAV on apache.org --000e0ce0b4dca38c1004a1a7b0fe Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sun, Apr 24, 2011 at 1:09 PM, Emmanuel L=E9charny = wrote: > On 4/24/11 11:48 AM, Alex Karasulu wrote: > >> Hi Emmanuel, >> >> On Sun, Apr 24, 2011 at 12:29 PM, Emmanuel Lecharny> >wrote: >> >> Hi, >>> >>> while checking the CascadeControl, I'm wondering f we use it at all in >>> the >>> server. I'm not sure either about its semantic. >>> >>> Alex, some insight maybe ? >>> >>> >>> Wow this one is really old. From what hazy memory I have of it, this >> control >> is a marker control. It has no payload from what I remember. >> >> The idea that drove creating it was to be able to issue subtree deletes.= I >> don't remember if there is an RFC or like minded control to do the same. >> Have not checked. Don't remember if we even looked. >> >> At some point PAM and I had some conversations about how to be able to >> manage some schema operations and cascade deletes had come up but I don'= t >> remember them now. >> >> I don't think the control is being used, if even referenced it might hav= e >> just had some scaffolding setup for it without actual use. >> > > AFAICT, it's only propagated to the schema handling part, and even there, > it's not used. > > If it has to be the treeDelete control, then I suggest we rename it and > modify the way we handle it in the server. Many LDAP server implement thi= s > treeDelete control (a draft issued by M$ peeps back in 2000), may be we > should have it... > +1 to following an exiting control defined in a draft or RFC rather than creating our own crap. Regards, Alex --000e0ce0b4dca38c1004a1a7b0fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sun, Apr 24, 2011 at 1:09 PM, Emmanue= l L=E9charny <= elecharny@apache.org> wrote:
On 4/24/11 11:48 AM, Alex Karasulu wrote:=
Hi Emmanuel,

On Sun, Apr 24, 2011 at 12:29 PM, Emmanuel Lecharny<elecharny@gmail.com>wrote:

Hi,

while checking the CascadeControl, I'm wondering f we use it at all in = the
server. I'm not sure either about its semantic.

Alex, some insight maybe ?


Wow this one is really old. From what hazy memory I have of it, this contro= l
is a marker control. It has no payload from what I remember.

The idea that drove creating it was to be able to issue subtree deletes. I<= br> don't remember if there is an RFC or like minded control to do the same= .
Have not checked. Don't remember if we even looked.

At some point PAM and I had some conversations about how to be able to
manage some schema operations and cascade deletes had come up but I don'= ;t
remember them now.

I don't think the control is being used, if even referenced it might ha= ve
just had some scaffolding setup for it without actual use.

AFAICT, it's only propagated to the schema handling part, and even ther= e, it's not used.

If it has to be the treeDelete control, then I suggest we rename it and mod= ify the way we handle it in the server. Many LDAP server implement this tre= eDelete control (a draft issued by M$ peeps back in 2000), may be we should= have it...

=
+1 to following an exiting control defined in a draft or RFC rather th= an creating our own crap.

Regards,
Alex<= /div>


--000e0ce0b4dca38c1004a1a7b0fe--