Re: Some more thoughts about the Dn class : Headsup
Hi, just to inform you that the following modifications has been done yesterday : Removed methods : Dn(String) Dn(SchemaManager, String) add(int, Rdn) add(int, String) Renamed methods : isChildOf(Dn) - isDescendantOf(Dn) isChildOf(String) - isDescendantOf(String) isParentOf(Dn) - isAncestorOf(Dn) isParentOf(String) - isAncestorOf(String) (we can sill discuss the final name to use) Added method : getSchemaManager() I will continue with the suggested modifications, assuming that those were the low hanging fruits... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Some more thoughts about the Dn class : Headsup
Thanks Emmanuel. This is going to be a very clean API. :) Regards, Pierre-Arnaud On vendredi 18 février 2011 at 09:52, Emmanuel Lecharny wrote: Hi, just to inform you that the following modifications has been done yesterday : Removed methods : Dn(String) Dn(SchemaManager, String) add(int, Rdn) add(int, String) Renamed methods : isChildOf(Dn) - isDescendantOf(Dn) isChildOf(String) - isDescendantOf(String) isParentOf(Dn) - isAncestorOf(Dn) isParentOf(String) - isAncestorOf(String) (we can sill discuss the final name to use) Added method : getSchemaManager() I will continue with the suggested modifications, assuming that those were the low hanging fruits... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Some more thoughts about the Dn class
On 2/17/11 12:43 AM, Alex Karasulu wrote: On Thu, Feb 17, 2011 at 1:20 AM, Emmanuel Lécharnyelecha...@apache.org wrote: On 2/17/11 12:03 AM, Alex Karasulu wrote: On Thu, Feb 17, 2011 at 12:55 AM, Emmanuel Lécharny elecha...@apache.orgwrote: On 2/16/11 9:02 PM, Alex Karasulu wrote: On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharnyelecha...@gmail.com wrote: Hi, we have had some convo about the Dn methods last night. Here are some of the things we discussed and came with : o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to manipulate. The main issue is that they depend on the RDN order, which is the opposite as what people are used to manipulate. Everytime you have to get a prefix from a Dn, you always wonder what the position should be, and if it's 0 based or 1 based... We propose to replace those methods by getParent(Dn) and getDescendant(Dn). Let me give you an example : // A DN Dn dn = new Dn( cn=test,ou=server,ou=directory,dc=apache,dc=org ); // Get the right part (equivalent to getprefix( 2 ) ) Dn parent = dn.getParent( cn=test,ou=server,ou=directory ); // returns dc=apache,dc=org // Get the left part (equivalent to getSuffix( 3 )) Dn descendant = dn.getDescendant( ou=directory,dc=apache,dc=org ); // returns cn=test,ou=server o The Add method is a bit annoying to remove, because first, the JNDI Name interface has such a method, and people are used to it, second removing it means we have to add some more constructors line Dn( Dn, Rdn... ). I agree that someone doing something like : Dn dn = new Dn( dc=apache,dc=org ); dn.add( ou=directory ); will expect that the dn is now ou=directory,dc=apache,dc=org, when it's unchanged. This is really troublesome... What about rename it concatenate() ? Thoughts ? Sounds good. But how about this: // not showing full Rdn but an index value representing the actual rdns in the dn for pos clarity Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” ); dn.getAncestorDn( “9, 8, 7, 6” ); = “5, 4, 3, 2, 1, 0” That's ok, but why not getParent() ? Because the result is not necessarily the parent of 'dn'. It may be if it's immediately superior. You're mixing together the meanings I think. Sorry, I don't get it. You have a DN, and you want the parent of it's left part, how possible the result couldn't be the parent ? If the parameter is not the left part, then you get an exception, but that's in the contract. Did I missed something ? The dn is “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” you're getting one of it's ancestors not it's parent. The parent would be “8, 7, 6, 5, 4, 3, 2, 1, 0”, the ancestor in the example is “5, 4, 3, 2, 1, 0”. You see what I mean? yes, but in the sample I gave it was : “9, 8, 7, 6, 5, 4, 3, 2, 1, 0”.getParent( 9, 8, 7, 6 ) which is 5, 4, 3, 2, 1, 0” The idea is that the parameter is the left part of the DN, and the getParent returns the right part. OTOH, “9, 8, 7, 6, 5, 4, 3, 2, 1, 0”.getParent() would return 8, 7, 6, 5, 4, 3, 2, 1, 0” -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Some more thoughts about the Dn class
On 2/17/11 12:43 AM, Alex Karasulu wrote: On Thu, Feb 17, 2011 at 1:20 AM, Emmanuel Lécharnyelecha...@apache.org wrote: On 2/17/11 12:03 AM, Alex Karasulu wrote: On Thu, Feb 17, 2011 at 12:55 AM, Emmanuel Lécharny elecha...@apache.orgwrote: On 2/16/11 9:02 PM, Alex Karasulu wrote: On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharnyelecha...@gmail.com wrote: Hi, we have had some convo about the Dn methods last night. Here are some of the things we discussed and came with : o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to manipulate. The main issue is that they depend on the RDN order, which is the opposite as what people are used to manipulate. Everytime you have to get a prefix from a Dn, you always wonder what the position should be, and if it's 0 based or 1 based... We propose to replace those methods by getParent(Dn) and getDescendant(Dn). Let me give you an example : // A DN Dn dn = new Dn( cn=test,ou=server,ou=directory,dc=apache,dc=org ); // Get the right part (equivalent to getprefix( 2 ) ) Dn parent = dn.getParent( cn=test,ou=server,ou=directory ); // returns dc=apache,dc=org // Get the left part (equivalent to getSuffix( 3 )) Dn descendant = dn.getDescendant( ou=directory,dc=apache,dc=org ); // returns cn=test,ou=server o The Add method is a bit annoying to remove, because first, the JNDI Name interface has such a method, and people are used to it, second removing it means we have to add some more constructors line Dn( Dn, Rdn... ). I agree that someone doing something like : Dn dn = new Dn( dc=apache,dc=org ); dn.add( ou=directory ); will expect that the dn is now ou=directory,dc=apache,dc=org, when it's unchanged. This is really troublesome... What about rename it concatenate() ? Thoughts ? Sounds good. But how about this: // not showing full Rdn but an index value representing the actual rdns in the dn for pos clarity Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” ); dn.getAncestorDn( “9, 8, 7, 6” ); = “5, 4, 3, 2, 1, 0” That's ok, but why not getParent() ? Because the result is not necessarily the parent of 'dn'. It may be if it's immediately superior. You're mixing together the meanings I think. Sorry, I don't get it. You have a DN, and you want the parent of it's left part, how possible the result couldn't be the parent ? If the parameter is not the left part, then you get an exception, but that's in the contract. Did I missed something ? The dn is “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” you're getting one of it's ancestors not it's parent. The parent would be “8, 7, 6, 5, 4, 3, 2, 1, 0”, the ancestor in the example is “5, 4, 3, 2, 1, 0”. You see what I mean? Alex Bottom line, it does not really matter... What is important is that we agree on a name that express what the operation does. So, considering that a DN can be expressed either as [RDN][DNp] or [DNd][DNa] with DNp = parent, DNa = ancestor, DNd = descendant (DNp and DNa are equivalent, it's just that a DNa may have a DNd, when a DNp can only ave a RDN) : * Dn.getParent() - returns the DNp in [RDN][DNp] * Dn.getAncestor( DNd ) - returns the DNa in [DNd][DNa] * Dn.getDescendant( DNa ) - returns the DNd in [DNd][DNa] Is that ok ? Should we use something more clear, like getAncestorOf/getDescendantOf ? Or use getAscendant/getDescendant ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Some more thoughts about the Dn class
On Thu, Feb 17, 2011 at 9:37 AM, Emmanuel Lécharny elecha...@apache.org wrote: On 2/17/11 12:43 AM, Alex Karasulu wrote: On Thu, Feb 17, 2011 at 1:20 AM, Emmanuel Lécharnyelecha...@apache.org wrote: On 2/17/11 12:03 AM, Alex Karasulu wrote: On Thu, Feb 17, 2011 at 12:55 AM, Emmanuel Lécharny elecha...@apache.org wrote: On 2/16/11 9:02 PM, Alex Karasulu wrote: On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharnyelecha...@gmail.com wrote: Hi, we have had some convo about the Dn methods last night. Here are some of the things we discussed and came with : o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to manipulate. The main issue is that they depend on the RDN order, which is the opposite as what people are used to manipulate. Everytime you have to get a prefix from a Dn, you always wonder what the position should be, and if it's 0 based or 1 based... We propose to replace those methods by getParent(Dn) and getDescendant(Dn). Let me give you an example : // A DN Dn dn = new Dn( cn=test,ou=server,ou=directory,dc=apache,dc=org ); // Get the right part (equivalent to getprefix( 2 ) ) Dn parent = dn.getParent( cn=test,ou=server,ou=directory ); // returns dc=apache,dc=org // Get the left part (equivalent to getSuffix( 3 )) Dn descendant = dn.getDescendant( ou=directory,dc=apache,dc=org ); // returns cn=test,ou=server o The Add method is a bit annoying to remove, because first, the JNDI Name interface has such a method, and people are used to it, second removing it means we have to add some more constructors line Dn( Dn, Rdn... ). I agree that someone doing something like : Dn dn = new Dn( dc=apache,dc=org ); dn.add( ou=directory ); will expect that the dn is now ou=directory,dc=apache,dc=org, when it's unchanged. This is really troublesome... What about rename it concatenate() ? Thoughts ? Sounds good. But how about this: // not showing full Rdn but an index value representing the actual rdns in the dn for pos clarity Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” ); dn.getAncestorDn( “9, 8, 7, 6” ); = “5, 4, 3, 2, 1, 0” That's ok, but why not getParent() ? Because the result is not necessarily the parent of 'dn'. It may be if it's immediately superior. You're mixing together the meanings I think. Sorry, I don't get it. You have a DN, and you want the parent of it's left part, how possible the result couldn't be the parent ? If the parameter is not the left part, then you get an exception, but that's in the contract. Did I missed something ? The dn is “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” you're getting one of it's ancestors not it's parent. The parent would be “8, 7, 6, 5, 4, 3, 2, 1, 0”, the ancestor in the example is “5, 4, 3, 2, 1, 0”. You see what I mean? Alex Bottom line, it does not really matter... What is important is that we agree on a name that express what the operation does. So, considering that a DN can be expressed either as [RDN][DNp] or [DNd][DNa] with DNp = parent, DNa = ancestor, DNd = descendant (DNp and DNa are equivalent, it's just that a DNa may have a DNd, when a DNp can only ave a RDN) : * Dn.getParent() - returns the DNp in [RDN][DNp] * Dn.getAncestor( DNd ) - returns the DNa in [DNd][DNa] * Dn.getDescendant( DNa ) - returns the DNd in [DNd][DNa] +1, please also add that definition to the Javadoc, this is a really nice, short, and clean description what the methods do. Is that ok ? Should we use something more clear, like getAncestorOf/getDescendantOf ? Or use getAscendant/getDescendant ? I would prefer getAncestorOf/getDescendantOf. One concern: What is the use case of the getAncestorOf/getDescendantOf from the user's point of view? In the server and in studio such methods are useful (e.g. calculating the local name for ACI handling). But does the end user of the API really need those methods? I mean we should avoid to put methods into the Dn class that is only/mostly used in server and studio. Maybe a DnUtils class with static methods for advanced DN processing would help? Kind Regards, Stefan
Re: Some more thoughts about the Dn class
On 2/17/11 10:28 AM, Stefan Seelmann wrote: On Thu, Feb 17, 2011 at 9:37 AM, Emmanuel Lécharnyelecha...@apache.org wrote: On 2/17/11 12:43 AM, Alex Karasulu wrote: On Thu, Feb 17, 2011 at 1:20 AM, Emmanuel Lécharnyelecha...@apache.org wrote: On 2/17/11 12:03 AM, Alex Karasulu wrote: On Thu, Feb 17, 2011 at 12:55 AM, Emmanuel Lécharny elecha...@apache.org wrote: On 2/16/11 9:02 PM, Alex Karasulu wrote: On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharnyelecha...@gmail.com wrote: Hi, we have had some convo about the Dn methods last night. Here are some of the things we discussed and came with : o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to manipulate. The main issue is that they depend on the RDN order, which is the opposite as what people are used to manipulate. Everytime you have to get a prefix from a Dn, you always wonder what the position should be, and if it's 0 based or 1 based... We propose to replace those methods by getParent(Dn) and getDescendant(Dn). Let me give you an example : // A DN Dn dn = new Dn( cn=test,ou=server,ou=directory,dc=apache,dc=org ); // Get the right part (equivalent to getprefix( 2 ) ) Dn parent = dn.getParent( cn=test,ou=server,ou=directory ); // returns dc=apache,dc=org // Get the left part (equivalent to getSuffix( 3 )) Dn descendant = dn.getDescendant( ou=directory,dc=apache,dc=org ); // returns cn=test,ou=server o The Add method is a bit annoying to remove, because first, the JNDI Name interface has such a method, and people are used to it, second removing it means we have to add some more constructors line Dn( Dn, Rdn... ). I agree that someone doing something like : Dn dn = new Dn( dc=apache,dc=org ); dn.add( ou=directory ); will expect that the dn is now ou=directory,dc=apache,dc=org, when it's unchanged. This is really troublesome... What about rename it concatenate() ? Thoughts ? Sounds good. But how about this: // not showing full Rdn but an index value representing the actual rdns in the dn for pos clarity Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” ); dn.getAncestorDn( “9, 8, 7, 6” ); =“5, 4, 3, 2, 1, 0” That's ok, but why not getParent() ? Because the result is not necessarily the parent of 'dn'. It may be if it's immediately superior. You're mixing together the meanings I think. Sorry, I don't get it. You have a DN, and you want the parent of it's left part, how possible the result couldn't be the parent ? If the parameter is not the left part, then you get an exception, but that's in the contract. Did I missed something ? The dn is “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” you're getting one of it's ancestors not it's parent. The parent would be “8, 7, 6, 5, 4, 3, 2, 1, 0”, the ancestor in the example is “5, 4, 3, 2, 1, 0”. You see what I mean? Alex Bottom line, it does not really matter... What is important is that we agree on a name that express what the operation does. So, considering that a DN can be expressed either as [RDN][DNp] or [DNd][DNa] with DNp = parent, DNa = ancestor, DNd = descendant (DNp and DNa are equivalent, it's just that a DNa may have a DNd, when a DNp can only ave a RDN) : * Dn.getParent() - returns the DNp in [RDN][DNp] * Dn.getAncestor( DNd ) - returns the DNa in [DNd][DNa] * Dn.getDescendant( DNa ) - returns the DNd in [DNd][DNa] +1, please also add that definition to the Javadoc, this is a really nice, short, and clean description what the methods do. Yes, sure, will do. Is that ok ? Should we use something more clear, like getAncestorOf/getDescendantOf ? Or use getAscendant/getDescendant ? I would prefer getAncestorOf/getDescendantOf. One concern: What is the use case of the getAncestorOf/getDescendantOf from the user's point of view? In the server and in studio such methods are useful (e.g. calculating the local name for ACI handling). But does the end user of the API really need those methods? I mean we should avoid to put methods into the Dn class that is only/mostly used in server and studio. Maybe a DnUtils class with static methods for advanced DN processing would help? Good point. I can see some case where you need to split the DN in two parts, for instance if you access two servers looking for an entry for which you have the name. For instance, if you have two ldap server, one in US and one in FR, you may have an entry present as cn=John Doe, dc=acme, c=us or cn=John Doe, dc=acme, c=fr, you may want to get the ancestor to know in which server the entry is stored into. Know, we can also provide some helper class to do that, but I'm afraid users will 'torture' the DN instead of using the DnUtils class, simply because hey won't know that such a class exists. Any opinion about the add() vs concatenate() methods ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Some more thoughts about the Dn class
On Thu, Feb 17, 2011 at 10:46 AM, Emmanuel Lecharny elecha...@gmail.com wrote: On 2/17/11 10:28 AM, Stefan Seelmann wrote: One concern: What is the use case of the getAncestorOf/getDescendantOf from the user's point of view? In the server and in studio such methods are useful (e.g. calculating the local name for ACI handling). But does the end user of the API really need those methods? I mean we should avoid to put methods into the Dn class that is only/mostly used in server and studio. Maybe a DnUtils class with static methods for advanced DN processing would help? Good point. I can see some case where you need to split the DN in two parts, for instance if you access two servers looking for an entry for which you have the name. For instance, if you have two ldap server, one in US and one in FR, you may have an entry present as cn=John Doe, dc=acme, c=us or cn=John Doe, dc=acme, c=fr, you may want to get the ancestor to know in which server the entry is stored into. Hm, in that case you need to know the exact left-part (in that case cn=John Doe, dc=acme) in order to call the getAnchestor() method, right? In that case a getAnchestor(1) would be more useful. Know, we can also provide some helper class to do that, but I'm afraid users will 'torture' the DN instead of using the DnUtils class, simply because hey won't know that such a class exists. Any opinion about the add() vs concatenate() methods ? What about getChild(), analog to getParent()? Dn.getChild(String); Dn.getChild(Dn); Dn.getChild(Rdn); Ok, get methods normally don't required a parameter. So a createChild() would also be better. WDYT? Kind Regards, Stefan
Re: Some more thoughts about the Dn class
On 2/17/11 11:07 AM, Stefan Seelmann wrote: On Thu, Feb 17, 2011 at 10:46 AM, Emmanuel Lecharnyelecha...@gmail.com wrote: On 2/17/11 10:28 AM, Stefan Seelmann wrote: One concern: What is the use case of the getAncestorOf/getDescendantOf from the user's point of view? In the server and in studio such methods are useful (e.g. calculating the local name for ACI handling). But does the end user of the API really need those methods? I mean we should avoid to put methods into the Dn class that is only/mostly used in server and studio. Maybe a DnUtils class with static methods for advanced DN processing would help? Good point. I can see some case where you need to split the DN in two parts, for instance if you access two servers looking for an entry for which you have the name. For instance, if you have two ldap server, one in US and one in FR, you may have an entry present as cn=John Doe, dc=acme, c=us or cn=John Doe, dc=acme, c=fr, you may want to get the ancestor to know in which server the entry is stored into. Hm, in that case you need to know the exact left-part (in that case cn=John Doe, dc=acme) in order to call the getAnchestor() method, right? In that case a getAnchestor(1) would be more useful. Yes, but we don't want to use the indexes for such operation, because users *never* now if the index is from the left or from the right. Add to that the fact that you also have to remember if it's a 0 based or 1 based index ... Know, we can also provide some helper class to do that, but I'm afraid users will 'torture' the DN instead of using the DnUtils class, simply because hey won't know that such a class exists. Any opinion about the add() vs concatenate() methods ? What about getChild(), analog to getParent()? Dn.getChild(String); Dn.getChild(Dn); Dn.getChild(Rdn); Ok, get methods normally don't required a parameter. So a createChild() would also be better. WDYT? getChild() is getRdn(). getChild( RDN) doesn't make a lot of sense, does it ? Just to keep the semantic associated with the name, getRdn is closer to what the user might expect to use. May be getParent is not appropriate, we might want to use getBaseDn instead ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Some more thoughts about the Dn class
On Thu, Feb 17, 2011 at 10:37 AM, Emmanuel Lécharny elecha...@apache.org wrote: On 2/17/11 12:43 AM, Alex Karasulu wrote: On Thu, Feb 17, 2011 at 1:20 AM, Emmanuel Lécharnyelecha...@apache.org wrote: On 2/17/11 12:03 AM, Alex Karasulu wrote: On Thu, Feb 17, 2011 at 12:55 AM, Emmanuel Lécharny elecha...@apache.org wrote: On 2/16/11 9:02 PM, Alex Karasulu wrote: On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharnyelecha...@gmail.com wrote: Hi, we have had some convo about the Dn methods last night. Here are some of the things we discussed and came with : o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to manipulate. The main issue is that they depend on the RDN order, which is the opposite as what people are used to manipulate. Everytime you have to get a prefix from a Dn, you always wonder what the position should be, and if it's 0 based or 1 based... We propose to replace those methods by getParent(Dn) and getDescendant(Dn). Let me give you an example : // A DN Dn dn = new Dn( cn=test,ou=server,ou=directory,dc=apache,dc=org ); // Get the right part (equivalent to getprefix( 2 ) ) Dn parent = dn.getParent( cn=test,ou=server,ou=directory ); // returns dc=apache,dc=org // Get the left part (equivalent to getSuffix( 3 )) Dn descendant = dn.getDescendant( ou=directory,dc=apache,dc=org ); // returns cn=test,ou=server o The Add method is a bit annoying to remove, because first, the JNDI Name interface has such a method, and people are used to it, second removing it means we have to add some more constructors line Dn( Dn, Rdn... ). I agree that someone doing something like : Dn dn = new Dn( dc=apache,dc=org ); dn.add( ou=directory ); will expect that the dn is now ou=directory,dc=apache,dc=org, when it's unchanged. This is really troublesome... What about rename it concatenate() ? Thoughts ? Sounds good. But how about this: // not showing full Rdn but an index value representing the actual rdns in the dn for pos clarity Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” ); dn.getAncestorDn( “9, 8, 7, 6” ); = “5, 4, 3, 2, 1, 0” That's ok, but why not getParent() ? Because the result is not necessarily the parent of 'dn'. It may be if it's immediately superior. You're mixing together the meanings I think. Sorry, I don't get it. You have a DN, and you want the parent of it's left part, how possible the result couldn't be the parent ? If the parameter is not the left part, then you get an exception, but that's in the contract. Did I missed something ? The dn is “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” you're getting one of it's ancestors not it's parent. The parent would be “8, 7, 6, 5, 4, 3, 2, 1, 0”, the ancestor in the example is “5, 4, 3, 2, 1, 0”. You see what I mean? Alex Bottom line, it does not really matter... What is important is that we agree on a name that express what the operation does. It does matter even if its a very subtle difference. You're trying to convey meaning avoiding ambiguity. Ancestor and parent have different meanings and we're just trying to use them correctly in our API. So, considering that a DN can be expressed either as [RDN][DNp] or [DNd][DNa] with DNp = parent, DNa = ancestor, DNd = descendant (DNp and DNa are equivalent, it's just that a DNa may have a DNd, when a DNp can only ave a RDN) : * Dn.getParent() - returns the DNp in [RDN][DNp] I agree with this. I think this is the correct usage of parent. It's the immediate ancestor. * Dn.getAncestor( DNd ) - returns the DNa in [DNd][DNa] +1 * Dn.getDescendant( DNa ) - returns the DNd in [DNd][DNa] +1 Is that ok ? Just perfect. I think we were thinking the same thing all along. The problem was expressing this. Should we use something more clear, like getAncestorOf/getDescendantOf ? Or use getAscendant/getDescendant ? Yeah getAncestorOf/getDescendantOf sounds like it flows better and clarifies that we're taking this from the dn the operation is applied to. Regards, Alex
Re: Some more thoughts about the Dn class
On Thu, Feb 17, 2011 at 12:55 AM, Emmanuel Lécharny elecha...@apache.org wrote: On 2/16/11 9:02 PM, Alex Karasulu wrote: On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharnyelecha...@gmail.com wrote: Hi, we have had some convo about the Dn methods last night. Here are some of the things we discussed and came with : o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to manipulate. The main issue is that they depend on the RDN order, which is the opposite as what people are used to manipulate. Everytime you have to get a prefix from a Dn, you always wonder what the position should be, and if it's 0 based or 1 based... We propose to replace those methods by getParent(Dn) and getDescendant(Dn). Let me give you an example : // A DN Dn dn = new Dn( cn=test,ou=server,ou=directory,dc=apache,dc=org ); // Get the right part (equivalent to getprefix( 2 ) ) Dn parent = dn.getParent( cn=test,ou=server,ou=directory ); // returns dc=apache,dc=org // Get the left part (equivalent to getSuffix( 3 )) Dn descendant = dn.getDescendant( ou=directory,dc=apache,dc=org ); // returns cn=test,ou=server o The Add method is a bit annoying to remove, because first, the JNDI Name interface has such a method, and people are used to it, second removing it means we have to add some more constructors line Dn( Dn, Rdn... ). I agree that someone doing something like : Dn dn = new Dn( dc=apache,dc=org ); dn.add( ou=directory ); will expect that the dn is now ou=directory,dc=apache,dc=org, when it's unchanged. This is really troublesome... What about rename it concatenate() ? Thoughts ? Sounds good. But how about this: // not showing full Rdn but an index value representing the actual rdns in the dn for pos clarity Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” ); dn.getAncestorDn( “9, 8, 7, 6” ); = “5, 4, 3, 2, 1, 0” That's ok, but why not getParent() ? getAncestorDn() is lng. I'd rather use getAncestor(), but I find it more user friendly to use getParent() In the end, getAncestorOf() is just as long as getAncestorDn() and this is the conclusion we came to in previous posts. Generally shorter is better I do agree with you 100%. However we're in a sticky area here where it's not so easy to describe the method with a single English word. So we're going to have to compromise a little for the sake of clarity. dn.getDnToAncestor( “1, 0” ); Again, the name is frankly difficult to understand, and also confusing (getDnToAncestor ? getAncestorDn ? Which one does what ?). The reason why I rearranged this from getDescendantOf() which I do prefer myself is because of a key difference in the returned Dn. It's a path difference. The getAncestorOf returns something from the root of the original Dn being operated on like so: Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” ); dn.getAncestorDn( “9, 8, 7, 6” ); = “5, 4, 3, 2, 1, 0” But getDescendantOf( 1, 0 ) returns a relative path from the leaf up to the referenced node: “9, 8, 7, 6, 5, 4, 3, 2 Without context we cannot be certain if the original Dn was an absolute path from the root. However what we do know is that getDescendantOf always returns a relative path from the leaf node up to some ancestor. Hence why I tried to express this in the identifier for the method getDnToAncestor(). getDnToAncestor connotates getting a Dn from somewhere below an ancestor up to that ancestor but not all the way to the root. So it's clear that we're dealing with a relative Dn for sure. What's irritating me is that getAncestorOf() returns a Dn which shares a common lineage with the dn operated on. If the original Dn is absolute we know that getAncestorOf returns an absolute Dn. But getDescendantOf is not the same, it always returns a relative Dn. So these two operations are not very symmetric when it comes to what they return. If getDescendantOf was returning an absolute Dn to a descendant of an ancestor that's a different case. So I have a problem with hinting symmetry here with getAncestorOf and getDescendantOf because it can be potentially misleading. I'd rather choose an identifier that clearly shows that a subpath is returned instead of using getDescendantOf. The best I could come up with was getDnToAncestor. Regards, Alex
Re: Some more thoughts about the Dn class
On 2/17/11 12:07 PM, Alex Karasulu wrote: getAncestorOf/getDescendantOf ? Or use getAscendant/getDescendant ? Yeah getAncestorOf/getDescendantOf sounds like it flows better and clarifies that we're taking this from the dn the operation is applied to. I like it better too. Will rename to use those names. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Some more thoughts about the Dn class
On Thu, Feb 17, 2011 at 2:19 PM, Emmanuel Lécharny elecha...@apache.org wrote: On 2/17/11 12:07 PM, Alex Karasulu wrote: getAncestorOf/getDescendantOf ? Or use getAscendant/getDescendant ? Yeah getAncestorOf/getDescendantOf sounds like it flows better and clarifies that we're taking this from the dn the operation is applied to. I like it better too. Will rename to use those names. Well hold on a second with the getDescendantOf operation. I think we have some outstanding issues with it. Please see my previous post. Regards, Alex
Re: Some more thoughts about the Dn class
On 2/17/11 1:27 PM, Alex Karasulu wrote: On Thu, Feb 17, 2011 at 2:19 PM, Emmanuel Lécharnyelecha...@apache.org wrote: On 2/17/11 12:07 PM, Alex Karasulu wrote: getAncestorOf/getDescendantOf ? Or use getAscendant/getDescendant ? Yeah getAncestorOf/getDescendantOf sounds like it flows better and clarifies that we're taking this from the dn the operation is applied to. I like it better too. Will rename to use those names. Well hold on a second with the getDescendantOf operation. I think we have some outstanding issues with it. Please see my previous post. I'm not closing the door here. Here is what I suggest : I'll move the API to use those name *for the moment*, in order to get rid of the old getPrefix/getSuffix names, but we can discuss those names further until the RC1. If we find a better name, I'll change them, it's a 5 mins task. I'm *not* considering that as final move, again. What is important is really to reach a point we all more or less agree, which is not easy, as it's not a technical matter, but much more a mix of many concerns : - semantic - ease of use - language (correct and accurate english) We should not expect to get the API defintion to be a breeze, I'm not really surprised that such things raise discussions like the one we are having. Frankly, if we were in a room, all of us, it would be exactly the same thing with people thinking this, other thinking that, etc, but nobody would hear about those disagreements outside the room. We are doing that in the open, and even if we don't agree on everything, at then end the result will be the same : we will reach consensus, and we will get something better than any decision made by one single person. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Some more thoughts about the Dn class
Heads up. Here are some suggested changes on the Dn API. The existing methods have a (e) prefix. The static methods have a (s) prefix. The added methods have a (+) prefix. The deleted methods have a (-) prefix. The renamed methods have a (r) prefix. Constructors : (e)Dn() (e)Dn(SchemaManager) (e)Dn(Rdn...) (e)Dn(SchemaManager, Rdn...) (-)Dn(String) not needed, the Dn(String...) can be used instead (-)Dn(SchemaManager, String) (e)Dn(String...) (e)Dn(SchemaManager, String...) (a)Dn(SchemaManager, Dn) (a)Dn(Dn, Rdn) - to create a new DN with a new RDN (-)add(String) (-)add(String…) (-)add(Rdn) (-)add(int, Rdn) (-)add(int, String) (-)addAll(Dn) (-)addAll(int, Dn) (-)addAllNormalized(int, Dn) (all replaced by constructor calls) (es) isNullOrEmpty(Dn) (es) isValid(String) (er) isChildOf(Dn) - isDescendantOf(Dn) (er) isChildOf(String) - isDescendantOf(String) (e)isEmpty() (-)isNormalized() - delete (er) isParentOf(Dn) - isAncestorOf(Dn) (er) isParentOf(String) - isAncestorOf(String) (e)isRootDSE() (?s) getBytes(Dn) - package protected/delete (?s) getNbBytes(Dn) - package protected/delete (-)get(int) - delete (e)getNormName() (e)getParent() (er) getParent(Dn) - getAncestorOf(Dn) (er) getParent(String) - getAncestorOf(String) (e)getRdn() (-)getRdn(int) (e)getRdns() (er) getSuffix(int) - getDescendantOf(Dn)/getDescendantOf(String) (+)getSchemaManager() - added (-)normalize(Dn, MapString, OidNormalizer) - delete (-)normalize(SchemaManager, String) - delete (-)normalize(SchemaManager) - delete (-)hasSuffix(Dn) - delete (-)remove(int) - delete (e)size() (e)equals(Object) (e)hashCode() (e)iterator() (e)toString() I won't change any of those methods unless we agreed on the operations, because it impacts the server and studio deeply, so I want to be sure we don't have to do that many times. Although as soon as we agree on some of them, I'll apply the agreed on modification in code. Thanks ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Some more thoughts about the Dn class
As we've reviewed this together, I'm +1 for all the modifications. Regards, Pierre-Arnaud On jeudi 17 février 2011 at 16:10, Emmanuel Lécharny wrote: Heads up. Here are some suggested changes on the Dn API. The existing methods have a (e) prefix. The static methods have a (s) prefix. The added methods have a (+) prefix. The deleted methods have a (-) prefix. The renamed methods have a (r) prefix. Constructors : (e) Dn() (e) Dn(SchemaManager) (e) Dn(Rdn...) (e) Dn(SchemaManager, Rdn...) (-) Dn(String) not needed, the Dn(String...) can be used instead (-) Dn(SchemaManager, String) (e) Dn(String...) (e) Dn(SchemaManager, String...) (a) Dn(SchemaManager, Dn) (a) Dn(Dn, Rdn) - to create a new DN with a new RDN (-) add(String) (-) add(String…) (-) add(Rdn) (-) add(int, Rdn) (-) add(int, String) (-) addAll(Dn) (-) addAll(int, Dn) (-) addAllNormalized(int, Dn) (all replaced by constructor calls) (es) isNullOrEmpty(Dn) (es) isValid(String) (er) isChildOf(Dn) - isDescendantOf(Dn) (er) isChildOf(String) - isDescendantOf(String) (e) isEmpty() (-) isNormalized() - delete (er) isParentOf(Dn) - isAncestorOf(Dn) (er) isParentOf(String) - isAncestorOf(String) (e) isRootDSE() (?s) getBytes(Dn) - package protected/delete (?s) getNbBytes(Dn) - package protected/delete (-) get(int) - delete (e) getNormName() (e) getParent() (er) getParent(Dn) - getAncestorOf(Dn) (er) getParent(String) - getAncestorOf(String) (e) getRdn() (-) getRdn(int) (e) getRdns() (er) getSuffix(int) - getDescendantOf(Dn)/getDescendantOf(String) (+) getSchemaManager() - added (-) normalize(Dn, MapString, OidNormalizer) - delete (-) normalize(SchemaManager, String) - delete (-) normalize(SchemaManager) - delete (-) hasSuffix(Dn) - delete (-) remove(int) - delete (e) size() (e) equals(Object) (e) hashCode() (e) iterator() (e) toString() I won't change any of those methods unless we agreed on the operations, because it impacts the server and studio deeply, so I want to be sure we don't have to do that many times. Although as soon as we agree on some of them, I'll apply the agreed on modification in code. Thanks ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Some more thoughts about the Dn class
On Thu, Feb 17, 2011 at 3:00 PM, Emmanuel Lécharny elecha...@apache.org wrote: On 2/17/11 1:27 PM, Alex Karasulu wrote: On Thu, Feb 17, 2011 at 2:19 PM, Emmanuel Lécharnyelecha...@apache.org wrote: On 2/17/11 12:07 PM, Alex Karasulu wrote: getAncestorOf/getDescendantOf ? Or use getAscendant/getDescendant ? Yeah getAncestorOf/getDescendantOf sounds like it flows better and clarifies that we're taking this from the dn the operation is applied to. I like it better too. Will rename to use those names. Well hold on a second with the getDescendantOf operation. I think we have some outstanding issues with it. Please see my previous post. I'm not closing the door here. Here is what I suggest : I'll move the API to use those name *for the moment*, in order to get rid of the old getPrefix/getSuffix names, but we can discuss those names further until the RC1. If we find a better name, I'll change them, it's a 5 mins task. I'm *not* considering that as final move, again. OK thanks. I just did not want to have someone say, 'we agreed to it this way'. What is important is really to reach a point we all more or less agree, which is not easy, as it's not a technical matter, but much more a mix of many concerns : - semantic - ease of use - language (correct and accurate english) Yes agreed. We should not expect to get the API defintion to be a breeze, I'm not really surprised that such things raise discussions like the one we are having. Frankly, if we were in a room, all of us, it would be exactly the same thing with people thinking this, other thinking that, etc, but nobody would hear about those disagreements outside the room. We are doing that in the open, and even if we don't agree on everything, at then end the result will be the same : we will reach consensus, and we will get something better than any decision made by one single person. Indeed. Thanks, Alex
Re: Some more thoughts about the Dn class
On Thu, Feb 17, 2011 at 5:10 PM, Emmanuel Lécharny elecha...@apache.org wrote: Heads up. Here are some suggested changes on the Dn API. The existing methods have a (e) prefix. The static methods have a (s) prefix. The added methods have a (+) prefix. The deleted methods have a (-) prefix. The renamed methods have a (r) prefix. Constructors : (e) Dn() (e) Dn(SchemaManager) (e) Dn(Rdn...) (e) Dn(SchemaManager, Rdn...) (-) Dn(String) not needed, the Dn(String...) can be used instead (-) Dn(SchemaManager, String) (e) Dn(String...) (e) Dn(SchemaManager, String...) (a) Dn(SchemaManager, Dn) (a) Dn(Dn, Rdn) - to create a new DN with a new RDN (-) add(String) (-) add(String…) (-) add(Rdn) (-) add(int, Rdn) (-) add(int, String) (-) addAll(Dn) (-) addAll(int, Dn) (-) addAllNormalized(int, Dn) (all replaced by constructor calls) (es) isNullOrEmpty(Dn) (es) isValid(String) (er) isChildOf(Dn) - isDescendantOf(Dn) (er) isChildOf(String) - isDescendantOf(String) (e) isEmpty() (-) isNormalized() - delete (er) isParentOf(Dn) - isAncestorOf(Dn) (er) isParentOf(String) - isAncestorOf(String) (e) isRootDSE() (?s) getBytes(Dn) - package protected/delete (?s) getNbBytes(Dn) - package protected/delete (-) get(int) - delete (e) getNormName() (e) getParent() (er) getParent(Dn) - getAncestorOf(Dn) (er) getParent(String) - getAncestorOf(String) (e) getRdn() (-) getRdn(int) (e) getRdns() (er) getSuffix(int) - getDescendantOf(Dn)/getDescendantOf(String) (+) getSchemaManager() - added (-) normalize(Dn, MapString, OidNormalizer) - delete (-) normalize(SchemaManager, String) - delete (-) normalize(SchemaManager) - delete (-) hasSuffix(Dn) - delete (-) remove(int) - delete (e) size() (e) equals(Object) (e) hashCode() (e) iterator() (e) toString() I won't change any of those methods unless we agreed on the operations, because it impacts the server and studio deeply, so I want to be sure we don't have to do that many times. Although as soon as we agree on some of them, I'll apply the agreed on modification in code. OK go ahead. Alex
Re: Some more thoughts about the Dn class
On 2/17/11 6:53 PM, Alex Karasulu wrote: On Thu, Feb 17, 2011 at 5:10 PM, Emmanuel Lécharnyelecha...@apache.org wrote: Heads up. Here are some suggested changes on the Dn API. The existing methods have a (e) prefix. The static methods have a (s) prefix. The added methods have a (+) prefix. The deleted methods have a (-) prefix. The renamed methods have a (r) prefix. Constructors : (e)Dn() (e)Dn(SchemaManager) (e)Dn(Rdn...) (e)Dn(SchemaManager, Rdn...) (-)Dn(String) not needed, the Dn(String...) can be used instead (-)Dn(SchemaManager, String) (e)Dn(String...) (e)Dn(SchemaManager, String...) (a)Dn(SchemaManager, Dn) (a)Dn(Dn, Rdn) -to create a new DN with a new RDN (-)add(String) (-)add(String…) (-)add(Rdn) (-)add(int, Rdn) (-)add(int, String) (-)addAll(Dn) (-)addAll(int, Dn) (-)addAllNormalized(int, Dn) (all replaced by constructor calls) (es) isNullOrEmpty(Dn) (es) isValid(String) (er) isChildOf(Dn) -isDescendantOf(Dn) (er) isChildOf(String) -isDescendantOf(String) (e)isEmpty() (-)isNormalized() -delete (er) isParentOf(Dn) -isAncestorOf(Dn) (er) isParentOf(String) -isAncestorOf(String) (e)isRootDSE() (?s) getBytes(Dn) -package protected/delete (?s) getNbBytes(Dn) -package protected/delete (-)get(int) -delete (e)getNormName() (e)getParent() (er) getParent(Dn) -getAncestorOf(Dn) (er) getParent(String) -getAncestorOf(String) (e)getRdn() (-)getRdn(int) (e)getRdns() (er) getSuffix(int) -getDescendantOf(Dn)/getDescendantOf(String) (+)getSchemaManager() -added (-)normalize(Dn, MapString, OidNormalizer) -delete (-)normalize(SchemaManager, String) -delete (-)normalize(SchemaManager) -delete (-)hasSuffix(Dn) -delete (-)remove(int) -delete (e)size() (e)equals(Object) (e)hashCode() (e)iterator() (e)toString() I won't change any of those methods unless we agreed on the operations, because it impacts the server and studio deeply, so I want to be sure we don't have to do that many times. Although as soon as we agree on some of them, I'll apply the agreed on modification in code. OK go ahead. Note that some modifications are *very expensive* : for instance, removing the Dn.normalize( SchemaManager ) has a huge impact on the server. Atm, i'm trying to see where inside the server we use not normalized Dn, and to remove them. If any of you have some issue with any of the actions to be applied to the Dn methods, feel free to speak your mind : I won't apply the modifications you don't like, until we reach a consensus. Thanks ! -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Some more thoughts about the Dn class
On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharny elecha...@gmail.com wrote: Hi, we have had some convo about the Dn methods last night. Here are some of the things we discussed and came with : o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to manipulate. The main issue is that they depend on the RDN order, which is the opposite as what people are used to manipulate. Everytime you have to get a prefix from a Dn, you always wonder what the position should be, and if it's 0 based or 1 based... We propose to replace those methods by getParent(Dn) and getDescendant(Dn). Let me give you an example : // A DN Dn dn = new Dn( cn=test,ou=server,ou=directory,dc=apache,dc=org ); // Get the right part (equivalent to getprefix( 2 ) ) Dn parent = dn.getParent( cn=test,ou=server,ou=directory ); // returns dc=apache,dc=org // Get the left part (equivalent to getSuffix( 3 )) Dn descendant = dn.getDescendant( ou=directory,dc=apache,dc=org ); // returns cn=test,ou=server o The Add method is a bit annoying to remove, because first, the JNDI Name interface has such a method, and people are used to it, second removing it means we have to add some more constructors line Dn( Dn, Rdn... ). I agree that someone doing something like : Dn dn = new Dn( dc=apache,dc=org ); dn.add( ou=directory ); will expect that the dn is now ou=directory,dc=apache,dc=org, when it's unchanged. This is really troublesome... What about rename it concatenate() ? Thoughts ? Sounds good. But how about this: // not showing full Rdn but an index value representing the actual rdns in the dn for pos clarity Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” ); dn.getAncestorDn( “9, 8, 7, 6” ); = “5, 4, 3, 2, 1, 0” dn.getAncestorDn( 6 ); = “5, 4, 3, 2, 1, 0” dn.getDnToAncestor( “1, 0” ); = “9, 8, 7, 6, 5, 4, 3, 2” dn.getDnToAncestor( 2 ); = “9, 8, 7, 6, 5, 4, 3, 2” Dn namingContext = “1, 0”; // all same below Dn dnAfterNamingContext = dn.getDnToAncestor( 1, 0 ); Dn dnAfterNamingContext = dn.getDnToAncestor( namingContext ); Dn dnAfterNamingContext = dn.getDnToAncestor( namingContext.size() ); Dn dnAfterNamingContext = dn.getDnToAncestor( namingContext.toString() ); dnAfterNamingContext === “9, 8, 7, 6, 5, 4, 3, 2” Overloads should be provided for Dn, String and int.
Re: Some more thoughts about the Dn class
On Wed, Feb 16, 2011 at 10:02 PM, Alex Karasulu akaras...@apache.org wrote: On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharny elecha...@gmail.com wrote: Hi, we have had some convo about the Dn methods last night. Here are some of the things we discussed and came with : o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to manipulate. The main issue is that they depend on the RDN order, which is the opposite as what people are used to manipulate. Everytime you have to get a prefix from a Dn, you always wonder what the position should be, and if it's 0 based or 1 based... We propose to replace those methods by getParent(Dn) and getDescendant(Dn). Let me give you an example : // A DN Dn dn = new Dn( cn=test,ou=server,ou=directory,dc=apache,dc=org ); // Get the right part (equivalent to getprefix( 2 ) ) Dn parent = dn.getParent( cn=test,ou=server,ou=directory ); // returns dc=apache,dc=org // Get the left part (equivalent to getSuffix( 3 )) Dn descendant = dn.getDescendant( ou=directory,dc=apache,dc=org ); // returns cn=test,ou=server o The Add method is a bit annoying to remove, because first, the JNDI Name interface has such a method, and people are used to it, second removing it means we have to add some more constructors line Dn( Dn, Rdn... ). I agree that someone doing something like : Dn dn = new Dn( dc=apache,dc=org ); dn.add( ou=directory ); will expect that the dn is now ou=directory,dc=apache,dc=org, when it's unchanged. This is really troublesome... What about rename it concatenate() ? Thoughts ? Sounds good. But how about this: // not showing full Rdn but an index value representing the actual rdns in the dn for pos clarity Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” ); dn.getAncestorDn( “9, 8, 7, 6” ); = “5, 4, 3, 2, 1, 0” dn.getAncestorDn( 6 ); = “5, 4, 3, 2, 1, 0” dn.getDnToAncestor( “1, 0” ); = “9, 8, 7, 6, 5, 4, 3, 2” dn.getDnToAncestor( 2 ); = “9, 8, 7, 6, 5, 4, 3, 2” Dn namingContext = “1, 0”; // all same below Dn dnAfterNamingContext = dn.getDnToAncestor( 1, 0 ); Dn dnAfterNamingContext = dn.getDnToAncestor( namingContext ); Dn dnAfterNamingContext = dn.getDnToAncestor( namingContext.size() ); Dn dnAfterNamingContext = dn.getDnToAncestor( namingContext.toString() ); dnAfterNamingContext === “9, 8, 7, 6, 5, 4, 3, 2” Overloads should be provided for Dn, String and int. Maybe some convenience methods like: dn.isAncestor( namingContext ); namingContext.isDescendant( dn ); dn.isRelated( namingContext ); = i.e. two DNs in different namingContexts will not be related namingContext.isParent( dn ); dn.isChild( namingContext ); dn.isSibling( namingContext ); Regards, Alex
Re: Some more thoughts about the Dn class
On 2/16/11 9:02 PM, Alex Karasulu wrote: On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharnyelecha...@gmail.com wrote: Hi, we have had some convo about the Dn methods last night. Here are some of the things we discussed and came with : o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to manipulate. The main issue is that they depend on the RDN order, which is the opposite as what people are used to manipulate. Everytime you have to get a prefix from a Dn, you always wonder what the position should be, and if it's 0 based or 1 based... We propose to replace those methods by getParent(Dn) and getDescendant(Dn). Let me give you an example : // A DN Dn dn = new Dn( cn=test,ou=server,ou=directory,dc=apache,dc=org ); // Get the right part (equivalent to getprefix( 2 ) ) Dn parent = dn.getParent( cn=test,ou=server,ou=directory ); // returns dc=apache,dc=org // Get the left part (equivalent to getSuffix( 3 )) Dn descendant = dn.getDescendant( ou=directory,dc=apache,dc=org ); // returns cn=test,ou=server o The Add method is a bit annoying to remove, because first, the JNDI Name interface has such a method, and people are used to it, second removing it means we have to add some more constructors line Dn( Dn, Rdn... ). I agree that someone doing something like : Dn dn = new Dn( dc=apache,dc=org ); dn.add( ou=directory ); will expect that the dn is now ou=directory,dc=apache,dc=org, when it's unchanged. This is really troublesome... What about rename it concatenate() ? Thoughts ? Sounds good. But how about this: // not showing full Rdn but an index value representing the actual rdns in the dn for pos clarity Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” ); dn.getAncestorDn( “9, 8, 7, 6” ); = “5, 4, 3, 2, 1, 0” That's ok, but why not getParent() ? getAncestorDn() is lng. I'd rather use getAncestor(), but I find it more user friendly to use getParent() dn.getAncestorDn( 6 ); = “5, 4, 3, 2, 1, 0” Does not work. What if the initial dn is 9, 8, 7, 6, 5, 4, 6, 3, 2, 2, 0 ? dn.getDnToAncestor( “1, 0” ); Again, the name is frankly difficult to understand, and also confusing (getDnToAncestor ? getAncestorDn ? Which one does what ?). dn.getDescendant() is easier to understand, even if not perfect. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Some more thoughts about the Dn class
On 2/16/11 9:29 PM, Alex Karasulu wrote: On Wed, Feb 16, 2011 at 10:02 PM, Alex Karasuluakaras...@apache.org wrote: On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharnyelecha...@gmail.com wrote: Hi, we have had some convo about the Dn methods last night. Here are some of the things we discussed and came with : o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to manipulate. The main issue is that they depend on the RDN order, which is the opposite as what people are used to manipulate. Everytime you have to get a prefix from a Dn, you always wonder what the position should be, and if it's 0 based or 1 based... We propose to replace those methods by getParent(Dn) and getDescendant(Dn). Let me give you an example : // A DN Dn dn = new Dn( cn=test,ou=server,ou=directory,dc=apache,dc=org ); // Get the right part (equivalent to getprefix( 2 ) ) Dn parent = dn.getParent( cn=test,ou=server,ou=directory ); // returns dc=apache,dc=org // Get the left part (equivalent to getSuffix( 3 )) Dn descendant = dn.getDescendant( ou=directory,dc=apache,dc=org ); // returns cn=test,ou=server o The Add method is a bit annoying to remove, because first, the JNDI Name interface has such a method, and people are used to it, second removing it means we have to add some more constructors line Dn( Dn, Rdn... ). I agree that someone doing something like : Dn dn = new Dn( dc=apache,dc=org ); dn.add( ou=directory ); will expect that the dn is now ou=directory,dc=apache,dc=org, when it's unchanged. This is really troublesome... What about rename it concatenate() ? Thoughts ? Sounds good. But how about this: // not showing full Rdn but an index value representing the actual rdns in the dn for pos clarity Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” ); dn.getAncestorDn( “9, 8, 7, 6” ); = “5, 4, 3, 2, 1, 0” dn.getAncestorDn( 6 ); = “5, 4, 3, 2, 1, 0” dn.getDnToAncestor( “1, 0” ); = “9, 8, 7, 6, 5, 4, 3, 2” dn.getDnToAncestor( 2 ); = “9, 8, 7, 6, 5, 4, 3, 2” Dn namingContext = “1, 0”; // all same below Dn dnAfterNamingContext = dn.getDnToAncestor( 1, 0 ); Dn dnAfterNamingContext = dn.getDnToAncestor( namingContext ); Dn dnAfterNamingContext = dn.getDnToAncestor( namingContext.size() ); Dn dnAfterNamingContext = dn.getDnToAncestor( namingContext.toString() ); dnAfterNamingContext === “9, 8, 7, 6, 5, 4, 3, 2” Overloads should be provided for Dn, String and int. Maybe some convenience methods like: dn.isAncestor( namingContext ); namingContext.isDescendant( dn ); We may add such methods, sure. Again, I'd rather use isParent( Dn ). IsDescendant( Dn ) fits me. dn.isRelated( namingContext ); = i.e. two DNs in different namingContexts will not be related dn.hasParent( Dn ) sounds again simpler. Every time you peek a different name for the same element (ancestor, related, ...), you confuse the user. namingContext.isParent( dn ); dn.isChild( namingContext ); isChild is not good, as the child is supposed to be the RDN only. isDescendant() and hasDescendant() is ok IMO, unless we decide that child fits better (dn.getChild( Dn ), dn.isChild( dn ), dn.hasChild( dn )) I'd like to get the API as simple as possible, avoiding using different terminology to describe the same cocept, plus to keep it simple to remember (and here, xxxdescendant() is problematic, because it's not easy to type without doing a mistake. I'd rather use 'child', if we don't mind about the Rdn relation) -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Some more thoughts about the Dn class
On Thu, Feb 17, 2011 at 12:55 AM, Emmanuel Lécharny elecha...@apache.org wrote: On 2/16/11 9:02 PM, Alex Karasulu wrote: On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharnyelecha...@gmail.com wrote: Hi, we have had some convo about the Dn methods last night. Here are some of the things we discussed and came with : o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to manipulate. The main issue is that they depend on the RDN order, which is the opposite as what people are used to manipulate. Everytime you have to get a prefix from a Dn, you always wonder what the position should be, and if it's 0 based or 1 based... We propose to replace those methods by getParent(Dn) and getDescendant(Dn). Let me give you an example : // A DN Dn dn = new Dn( cn=test,ou=server,ou=directory,dc=apache,dc=org ); // Get the right part (equivalent to getprefix( 2 ) ) Dn parent = dn.getParent( cn=test,ou=server,ou=directory ); // returns dc=apache,dc=org // Get the left part (equivalent to getSuffix( 3 )) Dn descendant = dn.getDescendant( ou=directory,dc=apache,dc=org ); // returns cn=test,ou=server o The Add method is a bit annoying to remove, because first, the JNDI Name interface has such a method, and people are used to it, second removing it means we have to add some more constructors line Dn( Dn, Rdn... ). I agree that someone doing something like : Dn dn = new Dn( dc=apache,dc=org ); dn.add( ou=directory ); will expect that the dn is now ou=directory,dc=apache,dc=org, when it's unchanged. This is really troublesome... What about rename it concatenate() ? Thoughts ? Sounds good. But how about this: // not showing full Rdn but an index value representing the actual rdns in the dn for pos clarity Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” ); dn.getAncestorDn( “9, 8, 7, 6” ); = “5, 4, 3, 2, 1, 0” That's ok, but why not getParent() ? Because the result is not necessarily the parent of 'dn'. It may be if it's immediately superior. You're mixing together the meanings I think. getAncestorDn() is lng. I'd rather use getAncestor(), but I find it more user friendly to use getParent() dn.getAncestorDn( 6 ); = “5, 4, 3, 2, 1, 0” Does not work. What if the initial dn is 9, 8, 7, 6, 5, 4, 6, 3, 2, 2, 0 ? dn.getDnToAncestor( “1, 0” ); Again, the name is frankly difficult to understand, and also confusing (getDnToAncestor ? getAncestorDn ? Which one does what ?). dn.getDescendant() is easier to understand, even if not perfect. -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Some more thoughts about the Dn class
On 2/17/11 12:03 AM, Alex Karasulu wrote: On Thu, Feb 17, 2011 at 12:55 AM, Emmanuel Lécharny elecha...@apache.org wrote: On 2/16/11 9:02 PM, Alex Karasulu wrote: On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharnyelecha...@gmail.com wrote: Hi, we have had some convo about the Dn methods last night. Here are some of the things we discussed and came with : o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to manipulate. The main issue is that they depend on the RDN order, which is the opposite as what people are used to manipulate. Everytime you have to get a prefix from a Dn, you always wonder what the position should be, and if it's 0 based or 1 based... We propose to replace those methods by getParent(Dn) and getDescendant(Dn). Let me give you an example : // A DN Dn dn = new Dn( cn=test,ou=server,ou=directory,dc=apache,dc=org ); // Get the right part (equivalent to getprefix( 2 ) ) Dn parent = dn.getParent( cn=test,ou=server,ou=directory ); // returns dc=apache,dc=org // Get the left part (equivalent to getSuffix( 3 )) Dn descendant = dn.getDescendant( ou=directory,dc=apache,dc=org ); // returns cn=test,ou=server o The Add method is a bit annoying to remove, because first, the JNDI Name interface has such a method, and people are used to it, second removing it means we have to add some more constructors line Dn( Dn, Rdn... ). I agree that someone doing something like : Dn dn = new Dn( dc=apache,dc=org ); dn.add( ou=directory ); will expect that the dn is now ou=directory,dc=apache,dc=org, when it's unchanged. This is really troublesome... What about rename it concatenate() ? Thoughts ? Sounds good. But how about this: // not showing full Rdn but an index value representing the actual rdns in the dn for pos clarity Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” ); dn.getAncestorDn( “9, 8, 7, 6” ); =“5, 4, 3, 2, 1, 0” That's ok, but why not getParent() ? Because the result is not necessarily the parent of 'dn'. It may be if it's immediately superior. You're mixing together the meanings I think. Sorry, I don't get it. You have a DN, and you want the parent of it's left part, how possible the result couldn't be the parent ? If the parameter is not the left part, then you get an exception, but that's in the contract. Did I missed something ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Re: Some more thoughts about the Dn class
On Thu, Feb 17, 2011 at 1:20 AM, Emmanuel Lécharny elecha...@apache.org wrote: On 2/17/11 12:03 AM, Alex Karasulu wrote: On Thu, Feb 17, 2011 at 12:55 AM, Emmanuel Lécharny elecha...@apache.org wrote: On 2/16/11 9:02 PM, Alex Karasulu wrote: On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharnyelecha...@gmail.com wrote: Hi, we have had some convo about the Dn methods last night. Here are some of the things we discussed and came with : o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to manipulate. The main issue is that they depend on the RDN order, which is the opposite as what people are used to manipulate. Everytime you have to get a prefix from a Dn, you always wonder what the position should be, and if it's 0 based or 1 based... We propose to replace those methods by getParent(Dn) and getDescendant(Dn). Let me give you an example : // A DN Dn dn = new Dn( cn=test,ou=server,ou=directory,dc=apache,dc=org ); // Get the right part (equivalent to getprefix( 2 ) ) Dn parent = dn.getParent( cn=test,ou=server,ou=directory ); // returns dc=apache,dc=org // Get the left part (equivalent to getSuffix( 3 )) Dn descendant = dn.getDescendant( ou=directory,dc=apache,dc=org ); // returns cn=test,ou=server o The Add method is a bit annoying to remove, because first, the JNDI Name interface has such a method, and people are used to it, second removing it means we have to add some more constructors line Dn( Dn, Rdn... ). I agree that someone doing something like : Dn dn = new Dn( dc=apache,dc=org ); dn.add( ou=directory ); will expect that the dn is now ou=directory,dc=apache,dc=org, when it's unchanged. This is really troublesome... What about rename it concatenate() ? Thoughts ? Sounds good. But how about this: // not showing full Rdn but an index value representing the actual rdns in the dn for pos clarity Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” ); dn.getAncestorDn( “9, 8, 7, 6” ); = “5, 4, 3, 2, 1, 0” That's ok, but why not getParent() ? Because the result is not necessarily the parent of 'dn'. It may be if it's immediately superior. You're mixing together the meanings I think. Sorry, I don't get it. You have a DN, and you want the parent of it's left part, how possible the result couldn't be the parent ? If the parameter is not the left part, then you get an exception, but that's in the contract. Did I missed something ? The dn is “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” you're getting one of it's ancestors not it's parent. The parent would be “8, 7, 6, 5, 4, 3, 2, 1, 0”, the ancestor in the example is “5, 4, 3, 2, 1, 0”. You see what I mean? Alex
