On Jan 13, 2010, at 1:03 PM, Francois wrote:

> Le 13/01/2010 12:24, Matthew Swift a écrit :
>> Hi Emmanuel,
> 
> I'm just giveng my point of view about the following, I don't think I can be 
> relevant elsewhere:
> 
>> Also, I strongly believe that DNs and RDNs and AVAs should be immutable
>> objects (as well as any other low level API type). What do you think?
> 
> I will go further : DN, RDN and AVA should be immutable, but Attribute should 
> be immutable too, and Entry should have at least an immutable DN (and 
> facilities to copy an entry with a new DN or ParentDN at factory level).
> 
> For attribute, the rationnal is that one replace attribute by a new one most 
> of the time,

That is true for attributes that hold a single value or very few.
However, not all attributes are single valued and I would strongly discourage 
anyone to do this for Groups where the members attribute can contain a huge 
number of values (yes we have customers with over 100 000 members in a group).


> and it's much easier to deal with immutable attribute - that's one of the 
> aspect of UnboundId SDK that I prefer.
> 
> For Entry's DN, it's linked to the fact that DN are almost IDs for entries. 
> So, the semantic of such an operation is much likely in two cases:
> - create a copy of an entry with another DN (change RDN but perhaps not 
> parentDN)
> - move an entry (only the parent DN change).
> These two cases (I hope I don't forget other ones) are easily fulfilled 
> througth factory-like method support.
> 
> 
> -- 
> Francois ARMAND
> http://fanf42.blogspot.com
> 

---
Ludovic Poitou                                    Sun Microsystems Inc.
OpenDS Community Manager            Directory Services          
http://blogs.sun.com/Ludo/         Grenoble Engineering Center - France

Join OpenDS, https://opends.dev.java.net/servlets/ProjectMembershipRequest

Sun Microsystems requires the following notice:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE:  This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~








Reply via email to