directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ludovic Poitou <Ludovic.Poi...@Sun.COM>
Subject Re: [DN] Existing API review
Date Wed, 13 Jan 2010 12:20:47 GMT

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
>> 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

Ludovic Poitou                                    Sun Microsystems Inc.
OpenDS Community Manager            Directory Services          Grenoble Engineering Center - France

Join OpenDS,

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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message