You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@apache.org> on 2009/07/23 01:27:18 UTC
Client API : Delete request
Hi guys,
following one thread started more than a month ago, I would like to get
your opinion about the DeleteRequest implementation.
We currently have the following methods (Thanks to Kiran who implemented
them) :
delete( LdapDN )
delete( LdapDN, boolean deleteChildren )
delete( LdapDN, DeleteListener )
delete( LdapDN, boolean deleteChildren, DeleteListener )
delete( DeleteRequest );
delete( DeleteRequest, DeleteListener );
If we exclude the last parameter, used only for asynchronous requests,
we have some other options :
- delete( String ) // instead of a LdapDN
- the boolean (deleteChildren) is associated with a control, we can pass
it to the DeleteRequest Object.
is the following list of methods enough then ? :
delete( String [, DeleteListener] )
delete( LdapDN [, DeleteListener] )
delete( DeleteRequest [, DeleteListener] )
Wdyt ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Client API : Delete request
Posted by Kiran Ayyagari <ay...@gmail.com>.
On Fri, Jul 31, 2009 at 10:24 AM, Emmanuel Lecharny <el...@apache.org>wrote:
> Kiran Ayyagari wrote:
>
>>
>> - deleteTree( DN ) will handle the LDAP protocol, nothing more (no
>>> control, nothing, no recursive deletion )
>>>
>> I think you mean - *recursive deletion*
>>
>
> sorry, I meant :
> delete(DN)
> not
> deleteTree(DN)
>
> so (no control, nothing, no recursive deletion )
>
hmm, quoting the original text again
<quote>
- delete( DN ) will handle the LDAP protocol, nothing more (no control,
nothing, no recursive deletion )
Plus regarding the recursive deletion :
- deleteTree( DN ) will handle the LDAP protocol, nothing more (no control,
nothing, *no* recursive deletion )
</quote>
the method deleteTree( DN ) requires recursive deletion, no? or you mean
that
we don't implement recursive deletion but we add the 'treeDelete control'
(1.2.840.113556.1.4.805) *if* the server supports this control?
> have made these changes a while back, haven't committed yet.
>
Ok ! I will be happy to see those commits in 5 days, when I will be back on
> line :)
>
have committed the code. Note that the current implementation of
deleteTree() uses
'treeDelete control' *if* the server supports and if not uses *recursive
deletition*
Let me know if the second approach is not intended in the core API.
thanks Emmanuel
Kiran Ayyagari
Re: Client API : Delete request
Posted by Emmanuel Lecharny <el...@apache.org>.
Kiran Ayyagari wrote:
>
>> - deleteTree( DN ) will handle the LDAP protocol, nothing more (no
>> control, nothing, no recursive deletion )
> I think you mean - *recursive deletion*
sorry, I meant :
delete(DN)
not
deleteTree(DN)
so (no control, nothing, no recursive deletion )
>> Also I see that the current code is using a boolean flag to do that,
>> and I don't think it's comfortable. The semantic is not as clear as a
>> deleteTree() method, IMHO.
>>
>> wdyt ?
>
> have made these changes a while back, haven't committed yet.
Ok ! I will be happy to see those commits in 5 days, when I will be back
on line :)
Thanks Kiran !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Client API : Delete request
Posted by Kiran Ayyagari <ay...@gmail.com>.
> - deleteTree( DN ) will handle the LDAP protocol, nothing more (no
> control, nothing, no recursive deletion )
I think you mean - *recursive deletion*
> - deleteTree( String dn ) for convenience
> - deleteTree( DeleteRequest ) will allow an advanced user to stuff the
> deleteRequest object with whatever controls he wants
> - deleteTree( DeleteRequest, Listener ) do the exact same thing,
> asynchronously
>
> Does it sounds good to you ?
yep
>
> PS : I was first considering the extended/helper things a good idea, but
> the more I think about it, the less I'm convinced it's convenient. Most
> new-ldappers really think that calling delete(DN) will remoive the entry
> *and* all of its children. Seing the deleteTree() method in the same
> LdapConnection class may help them to understand the difference.
this was exactly what I have in mind when writing a previous reply to this thread
>
> Also I see that the current code is using a boolean flag to do that, and
> I don't think it's comfortable. The semantic is not as clear as a
> deleteTree() method, IMHO.
>
> wdyt ?
have made these changes a while back, haven't committed yet.
>
> PS: I have updated the wiki to reflect this proposal, I have kept the
> code as it was.
thanks Emmanuel, will commit the code tonight
Kiran Ayyagari
Re: Client API : Delete request
Posted by Emmanuel Lecharny <el...@apache.org>.
So to freeze the delete() API, do we agree on that :
- delete( DN ) will handle the LDAP protocol, nothing more (no control,
nothing, no recursive deletion )
- delete( DeleteRequest ) will allow an advanced user to stuff the
deleteRequest object with whatever controls he wants
- delete( DeleteRequest, Listener ) do the exact same thing, asynchronously
And we can add something like :
- delete( String dn ) for convenience
Plus regarding the recursive deletion :
- deleteTree( DN ) will handle the LDAP protocol, nothing more (no
control, nothing, no recursive deletion )
- deleteTree( String dn ) for convenience
- deleteTree( DeleteRequest ) will allow an advanced user to stuff the
deleteRequest object with whatever controls he wants
- deleteTree( DeleteRequest, Listener ) do the exact same thing,
asynchronously
Does it sounds good to you ?
PS : I was first considering the extended/helper things a good idea, but
the more I think about it, the less I'm convinced it's convenient. Most
new-ldappers really think that calling delete(DN) will remoive the entry
*and* all of its children. Seing the deleteTree() method in the same
LdapConnection class may help them to understand the difference.
Also I see that the current code is using a boolean flag to do that, and
I don't think it's comfortable. The semantic is not as clear as a
deleteTree() method, IMHO.
wdyt ?
PS: I have updated the wiki to reflect this proposal, I have kept the
code as it was.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Client API : Delete request
Posted by Alex Karasulu <ak...@gmail.com>.
On Thu, Jul 23, 2009 at 9:41 AM, Emmanuel Lecharny <el...@apache.org>wrote:
> Alex Karasulu wrote:
>
>> BTW, with a client API we'll be encountering a spectrum of people who know
>> much to almost nothing about LDAP but all should be able to use it easily.
>> We need to think like our most ignorant users.
>>
> Totally agree.
>
>> A good API will talk to you
>> when you don't know anything. I know I've been a monkey myself looking at
>> API java docs to find a square peg to fill a square hole.
>>
> It's just a brute force issue ;)
>
>
> What design
>> decisions and conventions in the API will best direct confused and LDAP
>> ignorant users?
>>
>>
> The less we expose, the better. This is why we think that at some point,
> using an XXXRequest Object is probably a better option than using many
> parameters which won't talk to anyone at first site. Nothing is more
> annoying than a method with 7 parameters, most of them being String, for
> instance.
>
> Regarding the deleteTree method, the biggest risk is that it make the users
> think that this operation will work on any server.
It can work on any server we can swap the implementation under the hood
replacing it with either a control based approach if the control is
available on the target server or use a recursive implementation. We can
use the Abstract Method Pattern to implement it.
> That mean we have to check if the control exists on the server, and if not,
> write the reursive code to do so. Certainly not a hammer to put in all the
> users' hands ! Not to mention the danger of a quick and misleaded deleteTree
> done on the top of the DiT (remember this rm -rf / we all did once as root
> ;)
>
Right but UNIX allows it and if administrators don't guard against it then
it's their problem.
>
>
> In this case, we need to balance being true to the protocol (direct and
>> clear) with providing sufficient insulation to our less savvy users. One
>> should be able to delve in deeper to get more out of the API based on
>> their
>> own proficiency, needs, and exceptional situation in a direct fashion.
>> Meanwhile most common cases should be easy and not too involved while
>> still
>> remaining clear and direct with respect to the protocol and the LDAP
>> access
>> model.
>>
>>
> I think this is what we are targeting since day one.
Oh yes I noticed that - not saying this was not the case.
>
> This specific situation is a good example. Our least LDAP savvy users
>> will
>> just want to delete a node or an entire tree. They don't know jack about
>> controls. Most will not even want to learn about it - they just need to
>> scratch an itch. Let's let them scratch the itch without pain and they
>> will
>> be back again and again even when sometimes it will cost more to scratch
>> more complex itches. This is how our API will be more pleasant to use.
>> So
>> a user seeing this signature will know exactly what it means without even
>> reading the java doc statement. It's self explanatory.
>>
>>
> Yes. And we can do the same for the ModifyDN operation, splitting it in
> three methods : rename, move and moveAndRename.
>
>> Sorry for beating a dead horse to death especially with this example but I
>> want to impart how I would approach an access API in case it would help
>> during your design.
>>
>>
> He, why do you think we are asking on the ML about this API ? I'm most
> certainly biased too, and I really appreciate the feedback we get.
Heh yeah right.
>
>
> More important, the number of responses we get is a good sign that these
> definitions are *very* important to most of us, not to mention our potential
> users.
>
> This is, IMO, the best way to get a well designed API.
>
Aye!
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
Re: Client API : Delete request
Posted by Emmanuel Lecharny <el...@apache.org>.
Alex Karasulu wrote:
> BTW, with a client API we'll be encountering a spectrum of people who know
> much to almost nothing about LDAP but all should be able to use it easily.
> We need to think like our most ignorant users.
Totally agree.
> A good API will talk to you
> when you don't know anything. I know I've been a monkey myself looking at
> API java docs to find a square peg to fill a square hole.
It's just a brute force issue ;)
> What design
> decisions and conventions in the API will best direct confused and LDAP
> ignorant users?
>
The less we expose, the better. This is why we think that at some point,
using an XXXRequest Object is probably a better option than using many
parameters which won't talk to anyone at first site. Nothing is more
annoying than a method with 7 parameters, most of them being String, for
instance.
Regarding the deleteTree method, the biggest risk is that it make the
users think that this operation will work on any server. That mean we
have to check if the control exists on the server, and if not, write the
reursive code to do so. Certainly not a hammer to put in all the users'
hands ! Not to mention the danger of a quick and misleaded deleteTree
done on the top of the DiT (remember this rm -rf / we all did once as
root ;)
> In this case, we need to balance being true to the protocol (direct and
> clear) with providing sufficient insulation to our less savvy users. One
> should be able to delve in deeper to get more out of the API based on their
> own proficiency, needs, and exceptional situation in a direct fashion.
> Meanwhile most common cases should be easy and not too involved while still
> remaining clear and direct with respect to the protocol and the LDAP access
> model.
>
I think this is what we are targeting since day one.
> This specific situation is a good example. Our least LDAP savvy users will
> just want to delete a node or an entire tree. They don't know jack about
> controls. Most will not even want to learn about it - they just need to
> scratch an itch. Let's let them scratch the itch without pain and they will
> be back again and again even when sometimes it will cost more to scratch
> more complex itches. This is how our API will be more pleasant to use. So
> a user seeing this signature will know exactly what it means without even
> reading the java doc statement. It's self explanatory.
>
Yes. And we can do the same for the ModifyDN operation, splitting it in
three methods : rename, move and moveAndRename.
> Sorry for beating a dead horse to death especially with this example but I
> want to impart how I would approach an access API in case it would help
> during your design.
>
He, why do you think we are asking on the ML about this API ? I'm most
certainly biased too, and I really appreciate the feedback we get.
More important, the number of responses we get is a good sign that these
definitions are *very* important to most of us, not to mention our
potential users.
This is, IMO, the best way to get a well designed API.
Thanks for the feedback.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Client API : Delete request
Posted by Alex Karasulu <ak...@gmail.com>.
BTW, with a client API we'll be encountering a spectrum of people who know
much to almost nothing about LDAP but all should be able to use it easily.
We need to think like our most ignorant users. A good API will talk to you
when you don't know anything. I know I've been a monkey myself looking at
API java docs to find a square peg to fill a square hole. What design
decisions and conventions in the API will best direct confused and LDAP
ignorant users?
In this case, we need to balance being true to the protocol (direct and
clear) with providing sufficient insulation to our less savvy users. One
should be able to delve in deeper to get more out of the API based on their
own proficiency, needs, and exceptional situation in a direct fashion.
Meanwhile most common cases should be easy and not too involved while still
remaining clear and direct with respect to the protocol and the LDAP access
model.
This specific situation is a good example. Our least LDAP savvy users will
just want to delete a node or an entire tree. They don't know jack about
controls. Most will not even want to learn about it - they just need to
scratch an itch. Let's let them scratch the itch without pain and they will
be back again and again even when sometimes it will cost more to scratch
more complex itches. This is how our API will be more pleasant to use. So
a user seeing this signature will know exactly what it means without even
reading the java doc statement. It's self explanatory.
Sorry for beating a dead horse to death especially with this example but I
want to impart how I would approach an access API in case it would help
during your design.
Also note there are other currents that will also impact your design down
the line when you consider how this API can be used with ORM tools for LDAP,
things like connection pooling etc.
Anyways this is looking great. Wish I had a hand in more of the details.
On Thu, Jul 23, 2009 at 4:26 AM, Emmanuel Lecharny <el...@apache.org>wrote:
> Alex Karasulu wrote:
>
>> On Wed, Jul 22, 2009 at 7:27 PM, Emmanuel Lecharny <elecharny@apache.org
>> >wrote:
>>
>>
>>
>>> Hi guys,
>>>
>>> following one thread started more than a month ago, I would like to get
>>> your opinion about the DeleteRequest implementation.
>>>
>>> We currently have the following methods (Thanks to Kiran who implemented
>>> them) :
>>>
>>> delete( LdapDN )
>>> delete( LdapDN, boolean deleteChildren )
>>> delete( LdapDN, DeleteListener )
>>> delete( LdapDN, boolean deleteChildren, DeleteListener )
>>> delete( DeleteRequest );
>>> delete( DeleteRequest, DeleteListener );
>>>
>>>
>>>
>>
>> Why not have a delete() and a deleteTree() method and do away with the
>> deleteChildren parameter? The parameter permutes the number of method
>> overloads and I think it's just more clear to use another method name all
>> together due to the nature of the operation. Here's what this looks like:
>>
>> delete( LdapDN )
>> deleteTree( LdapDN )
>> delete( LdapDN, DeleteListener )
>> deleteTree( LdapDN, DeleteListener )
>>
>>
> That's an idea. We should also add some methods in order to allow a user to
> pass a String instead of a DN :
> delete( String )
> deleteTree( String )
> delete( String, DeleteListener )
> deleteTree( String,DeleteListener )
>
> I don't see the point to having delete take the DeleteRequest. I guess
>> this
>> is for convenience in the codec? If so then might this not be best a
>> package friendly method overload?
>>
>>
> It's just convenient if you have to add some controls.
>
>>
>>
>>
>>> If we exclude the last parameter, used only for asynchronous requests, we
>>> have some other options :
>>>
>>> - delete( String ) // instead of a LdapDN
>>> - the boolean (deleteChildren) is associated with a control, we can pass
>>> it
>>> to the DeleteRequest Object.
>>>
>>> is the following list of methods enough then ? :
>>> delete( String [, DeleteListener] )
>>> delete( LdapDN [, DeleteListener] )
>>> delete( DeleteRequest [, DeleteListener] )
>>>
>>>
>>>
>>
>> Hmmm if I want to delete a tree of entries then I will have no choice but
>> to
>> wrap my LdapDN in a DeleteRequest which I must now create, just to add the
>> control to delete the subtree.
>>
>>
> Yes, true. IMO, your proposal (deleteTree) is probably better.
>
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
Re: Client API : Delete request
Posted by Alex Karasulu <ak...@gmail.com>.
Oh and I do agree completely with Stefan's comments as well. Think of it
also this way. The less surface area exposed by the API the less of an
overhead it is to deal with things like deprecation etc.
Alex
On Thu, Jul 23, 2009 at 9:26 AM, Alex Karasulu <ak...@gmail.com> wrote:
> I like this idea with the DeleteHelper.
>
>
> On Thu, Jul 23, 2009 at 4:55 AM, Stefan Seelmann <se...@apache.org>wrote:
>
>> Emmanuel Lecharny wrote:
>> > Alex Karasulu wrote:
>> >> Hmmm if I want to delete a tree of entries then I will have no choice
>> >> but to
>> >> wrap my LdapDN in a DeleteRequest which I must now create, just to add
>> >> the
>> >> control to delete the subtree.
>> >>
>> > Yes, true. IMO, your proposal (deleteTree) is probably better.
>> >
>>
>> I think the main API shouldn't be overloaded with too much convenience
>> methods and should be close to the LDAP protocol. I also think the main
>> API should not implement such algorithms (if server supports
>> TreeDeleteControl use it, else search/delete recursively).
>>
>> What about putting these helpful convenience methods to a Helper class?
>> DeleteHelper.deleteTree( LdapConnection, LdapDN )
>> DeleteHelper.deleteChildren( LdapConnection, LdapDN)
>>
>> My 2 cents,
>> Stefan
>>
>
>
>
> --
> Alex Karasulu
> My Blog :: http://www.jroller.com/akarasulu/
> Apache Directory Server :: http://directory.apache.org
> Apache MINA :: http://mina.apache.org
>
>
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
Re: Client API : Delete request
Posted by Alex Karasulu <ak...@gmail.com>.
I like this idea with the DeleteHelper.
On Thu, Jul 23, 2009 at 4:55 AM, Stefan Seelmann <se...@apache.org>wrote:
> Emmanuel Lecharny wrote:
> > Alex Karasulu wrote:
> >> Hmmm if I want to delete a tree of entries then I will have no choice
> >> but to
> >> wrap my LdapDN in a DeleteRequest which I must now create, just to add
> >> the
> >> control to delete the subtree.
> >>
> > Yes, true. IMO, your proposal (deleteTree) is probably better.
> >
>
> I think the main API shouldn't be overloaded with too much convenience
> methods and should be close to the LDAP protocol. I also think the main
> API should not implement such algorithms (if server supports
> TreeDeleteControl use it, else search/delete recursively).
>
> What about putting these helpful convenience methods to a Helper class?
> DeleteHelper.deleteTree( LdapConnection, LdapDN )
> DeleteHelper.deleteChildren( LdapConnection, LdapDN)
>
> My 2 cents,
> Stefan
>
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
Re: Client API : Delete request
Posted by Alex Karasulu <ak...@gmail.com>.
On Sat, Jul 25, 2009 at 12:07 AM, Kiran Ayyagari <ay...@gmail.com>wrote:
>
> I think the main API shouldn't be overloaded with too much convenience
>> methods and should be close to the LDAP protocol. I also think the main
>> API should not implement such algorithms (if server supports
>> TreeDeleteControl use it, else search/delete recursively).
>>
>
> The current client-api does both, i.e checks if the server supports the
> 'treedelete'
> control, if Yes, then uses it else deletes recursively
>
>
>> What about putting these helpful convenience methods to a Helper class?
>> DeleteHelper.deleteTree( LdapConnection, LdapDN )
>> DeleteHelper.deleteChildren( LdapConnection, LdapDN)
>>
>
> IMHO, I don't think that the current API has *too* many methods with
> completely different
> semantics (after excluding the helpful overloaded methods), having said
> this, I prefer to apply
> the suggested changes on LdapConnection and lets review the whole public
> API again here and
> see if it is better to move some methods to corresponding XXXHelper
> classes.
>
+1
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
Re: Client API : Delete request
Posted by Kiran Ayyagari <ay...@gmail.com>.
> I think the main API shouldn't be overloaded with too much convenience
> methods and should be close to the LDAP protocol. I also think the main
> API should not implement such algorithms (if server supports
> TreeDeleteControl use it, else search/delete recursively).
The current client-api does both, i.e checks if the server supports the 'treedelete'
control, if Yes, then uses it else deletes recursively
>
> What about putting these helpful convenience methods to a Helper class?
> DeleteHelper.deleteTree( LdapConnection, LdapDN )
> DeleteHelper.deleteChildren( LdapConnection, LdapDN)
IMHO, I don't think that the current API has *too* many methods with completely different
semantics (after excluding the helpful overloaded methods), having said this, I prefer to apply
the suggested changes on LdapConnection and lets review the whole public API again here and
see if it is better to move some methods to corresponding XXXHelper classes.
Kiran Ayyagari
Re: Client API : Delete request
Posted by Stefan Seelmann <se...@apache.org>.
Alex Karasulu wrote:
> Maybe we can split the API in two parts :
> - the core API
> - an extended API (something like ldapx, as Sun define a javax)
>
> thoughts ?
>
>
> Pretty much agree but maybe we don't have to go to that degree. The
> helpers recommended sound nice.
>
> I don't want to talk for Stefan but I think he wants the reduced set of
> methods needed to just get the job done: sort of like the philosophy of
> RISC. We can expose more convenience utility methods that build on the
> minimal set to provide more convenience to our users outside of the
> minimal set without cluttering it. I like this thought process.
Yes, that are my thoughts :-)
I want an API that is close to the protocol. That gives an LDAP
experienced developer all the power of the protocol.
But I fully agree that a Java developer that just needs to do something
with LDAP should not be forced to study all RFCs before s/he could start.
Kind Regards,
Stefan
Re: Client API : Delete request
Posted by Alex Karasulu <ak...@gmail.com>.
On Thu, Jul 23, 2009 at 7:25 AM, Emmanuel Lecharny <el...@apache.org>wrote:
> Stefan Seelmann wrote:
>
>> Emmanuel Lecharny wrote:
>>
>>
>>> Alex Karasulu wrote:
>>>
>>>
>>>> Hmmm if I want to delete a tree of entries then I will have no choice
>>>> but to
>>>> wrap my LdapDN in a DeleteRequest which I must now create, just to add
>>>> the
>>>> control to delete the subtree.
>>>>
>>>>
>>> Yes, true. IMO, your proposal (deleteTree) is probably better.
>>>
>>>
>>>
>>
>> I think the main API shouldn't be overloaded with too much convenience
>> methods and should be close to the LDAP protocol. I also think the main
>> API should not implement such algorithms (if server supports
>> TreeDeleteControl use it, else search/delete recursively).
>>
>>
> You may be right. If the server does not support the control, what should
> we do ? Implement the recursive deletion cliennt side ? That does not make a
> lot of sense, IMO.
>
>> What about putting these helpful convenience methods to a Helper class?
>> DeleteHelper.deleteTree( LdapConnection, LdapDN )
>> DeleteHelper.deleteChildren( LdapConnection, LdapDN)
>>
>>
>
> Maybe we can split the API in two parts :
> - the core API
> - an extended API (something like ldapx, as Sun define a javax)
>
> thoughts ?
>
>
Pretty much agree but maybe we don't have to go to that degree. The helpers
recommended sound nice.
I don't want to talk for Stefan but I think he wants the reduced set of
methods needed to just get the job done: sort of like the philosophy of
RISC. We can expose more convenience utility methods that build on the
minimal set to provide more convenience to our users outside of the minimal
set without cluttering it. I like this thought process.
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
Re: Client API : Delete request
Posted by Emmanuel Lecharny <el...@apache.org>.
Stefan Seelmann wrote:
> Emmanuel Lecharny wrote:
>
>> You may be right. If the server does not support the control, what
>> should we do ? Implement the recursive deletion cliennt side ? That does
>> not make a lot of sense, IMO.
>>
>
> I think it makes sense. I don't know how often I implemented such a
> recursive deletion method in JNDI. I don't want to do it once more :-)
>
I hear you on that. Can you provide the code then, if you have it
somewhere ?
Thanks !
> Kind Regards,
> Stefan
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Client API : Delete request
Posted by Stefan Seelmann <se...@apache.org>.
Emmanuel Lecharny wrote:
> You may be right. If the server does not support the control, what
> should we do ? Implement the recursive deletion cliennt side ? That does
> not make a lot of sense, IMO.
I think it makes sense. I don't know how often I implemented such a
recursive deletion method in JNDI. I don't want to do it once more :-)
Kind Regards,
Stefan
Re: Client API : Delete request
Posted by Emmanuel Lecharny <el...@apache.org>.
Stefan Seelmann wrote:
> Emmanuel Lecharny wrote:
>
>> Alex Karasulu wrote:
>>
>>> Hmmm if I want to delete a tree of entries then I will have no choice
>>> but to
>>> wrap my LdapDN in a DeleteRequest which I must now create, just to add
>>> the
>>> control to delete the subtree.
>>>
>>>
>> Yes, true. IMO, your proposal (deleteTree) is probably better.
>>
>>
>
> I think the main API shouldn't be overloaded with too much convenience
> methods and should be close to the LDAP protocol. I also think the main
> API should not implement such algorithms (if server supports
> TreeDeleteControl use it, else search/delete recursively).
>
You may be right. If the server does not support the control, what
should we do ? Implement the recursive deletion cliennt side ? That does
not make a lot of sense, IMO.
> What about putting these helpful convenience methods to a Helper class?
> DeleteHelper.deleteTree( LdapConnection, LdapDN )
> DeleteHelper.deleteChildren( LdapConnection, LdapDN)
>
Maybe we can split the API in two parts :
- the core API
- an extended API (something like ldapx, as Sun define a javax)
thoughts ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Client API : Delete request
Posted by Stefan Seelmann <se...@apache.org>.
Emmanuel Lecharny wrote:
> Alex Karasulu wrote:
>> Hmmm if I want to delete a tree of entries then I will have no choice
>> but to
>> wrap my LdapDN in a DeleteRequest which I must now create, just to add
>> the
>> control to delete the subtree.
>>
> Yes, true. IMO, your proposal (deleteTree) is probably better.
>
I think the main API shouldn't be overloaded with too much convenience
methods and should be close to the LDAP protocol. I also think the main
API should not implement such algorithms (if server supports
TreeDeleteControl use it, else search/delete recursively).
What about putting these helpful convenience methods to a Helper class?
DeleteHelper.deleteTree( LdapConnection, LdapDN )
DeleteHelper.deleteChildren( LdapConnection, LdapDN)
My 2 cents,
Stefan
Re: Client API : Delete request
Posted by Emmanuel Lecharny <el...@apache.org>.
Alex Karasulu wrote:
> On Wed, Jul 22, 2009 at 7:27 PM, Emmanuel Lecharny <el...@apache.org>wrote:
>
>
>> Hi guys,
>>
>> following one thread started more than a month ago, I would like to get
>> your opinion about the DeleteRequest implementation.
>>
>> We currently have the following methods (Thanks to Kiran who implemented
>> them) :
>>
>> delete( LdapDN )
>> delete( LdapDN, boolean deleteChildren )
>> delete( LdapDN, DeleteListener )
>> delete( LdapDN, boolean deleteChildren, DeleteListener )
>> delete( DeleteRequest );
>> delete( DeleteRequest, DeleteListener );
>>
>>
>
> Why not have a delete() and a deleteTree() method and do away with the
> deleteChildren parameter? The parameter permutes the number of method
> overloads and I think it's just more clear to use another method name all
> together due to the nature of the operation. Here's what this looks like:
>
> delete( LdapDN )
> deleteTree( LdapDN )
> delete( LdapDN, DeleteListener )
> deleteTree( LdapDN, DeleteListener )
>
That's an idea. We should also add some methods in order to allow a user
to pass a String instead of a DN :
delete( String )
deleteTree( String )
delete( String, DeleteListener )
deleteTree( String,DeleteListener )
> I don't see the point to having delete take the DeleteRequest. I guess this
> is for convenience in the codec? If so then might this not be best a
> package friendly method overload?
>
It's just convenient if you have to add some controls.
>
>
>> If we exclude the last parameter, used only for asynchronous requests, we
>> have some other options :
>>
>> - delete( String ) // instead of a LdapDN
>> - the boolean (deleteChildren) is associated with a control, we can pass it
>> to the DeleteRequest Object.
>>
>> is the following list of methods enough then ? :
>> delete( String [, DeleteListener] )
>> delete( LdapDN [, DeleteListener] )
>> delete( DeleteRequest [, DeleteListener] )
>>
>>
>
> Hmmm if I want to delete a tree of entries then I will have no choice but to
> wrap my LdapDN in a DeleteRequest which I must now create, just to add the
> control to delete the subtree.
>
Yes, true. IMO, your proposal (deleteTree) is probably better.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Client API : Delete request
Posted by Kiran Ayyagari <ay...@gmail.com>.
> Why not have a delete() and a deleteTree() method and do away with the
> deleteChildren parameter? The parameter permutes the number of method
> overloads
yeap, an excellent catch
and I think it's just more clear to use another method name
> all together due to the nature of the operation. Here's what this looks
> like:
>
> delete( LdapDN )
> deleteTree( LdapDN )
> delete( LdapDN, DeleteListener )
> deleteTree( LdapDN, DeleteListener )
+1, I liked it
>
> I don't see the point to having delete take the DeleteRequest. I guess
> this is for convenience in the codec?
the reason is to let the user add any controls if he wants to and also all operations
have their respective operation type XXXRequest object to support this.
> is the following list of methods enough then ? :
> delete( String [, DeleteListener] )
> delete( LdapDN [, DeleteListener] )
> delete( DeleteRequest [, DeleteListener] )
>
>
> Hmmm if I want to delete a tree of entries then I will have no choice
> but to wrap my LdapDN in a DeleteRequest which I must now create, just
> to add the control to delete the subtree.
I think with a method like deleteTree() the user is no longer forced to create this request
as we assume that this is 'deleteChildren' and add the supported controls(or let the client do recursive delete)
so this last method 'delete( DeleteRequest [, DeleteListener] )' just stays there for convenience of adding any special
controls user want to(as said above)
thanks Alex
Kiran Ayyagari
Re: Client API : Delete request
Posted by Alex Karasulu <ak...@gmail.com>.
On Wed, Jul 22, 2009 at 7:27 PM, Emmanuel Lecharny <el...@apache.org>wrote:
> Hi guys,
>
> following one thread started more than a month ago, I would like to get
> your opinion about the DeleteRequest implementation.
>
> We currently have the following methods (Thanks to Kiran who implemented
> them) :
>
> delete( LdapDN )
> delete( LdapDN, boolean deleteChildren )
> delete( LdapDN, DeleteListener )
> delete( LdapDN, boolean deleteChildren, DeleteListener )
> delete( DeleteRequest );
> delete( DeleteRequest, DeleteListener );
>
Why not have a delete() and a deleteTree() method and do away with the
deleteChildren parameter? The parameter permutes the number of method
overloads and I think it's just more clear to use another method name all
together due to the nature of the operation. Here's what this looks like:
delete( LdapDN )
deleteTree( LdapDN )
delete( LdapDN, DeleteListener )
deleteTree( LdapDN, DeleteListener )
I don't see the point to having delete take the DeleteRequest. I guess this
is for convenience in the codec? If so then might this not be best a
package friendly method overload?
>
> If we exclude the last parameter, used only for asynchronous requests, we
> have some other options :
>
> - delete( String ) // instead of a LdapDN
> - the boolean (deleteChildren) is associated with a control, we can pass it
> to the DeleteRequest Object.
>
> is the following list of methods enough then ? :
> delete( String [, DeleteListener] )
> delete( LdapDN [, DeleteListener] )
> delete( DeleteRequest [, DeleteListener] )
>
Hmmm if I want to delete a tree of entries then I will have no choice but to
wrap my LdapDN in a DeleteRequest which I must now create, just to add the
control to delete the subtree.
--
Alex Karasulu
My Blog :: http://www.jroller.com/akarasulu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org