directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Swift <Matthew.Sw...@Sun.COM>
Subject Re: [DN] Existing API review
Date Thu, 14 Jan 2010 21:21:51 GMT

On 13/01/10 13:34, Emmanuel LŽcharny wrote:
> Francois a écrit :
>> 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
> +1

+1 from me too.

>> but Attribute should be immutable too, 
> Well, it would be a bit inconvenient when manipulating values...

It is - believe me. I had everyone complaining about it to me! :-)

>> and Entry should have at least an immutable DN (and facilities to 
>> copy an entry with a new DN or ParentDN at factory level).
> If the DN is immutable, entry's DN will be too.

I think Francois is stating that Entry should have a DN getter but no 
setter. In other words the DN is set during construction and cannot be 
changed afterwards. I personally think that this restriction is a bit 
artificial. A similar artificial constraint could be imposed on the 
objectClass attribute (i.e. don't allow the structural object class to 
be changed). Whilst technically correct at the LDAP protocol level, I 
don't think that these constraints should be imposed at the API level. 
For example, imagine a GUI for creating a new user entry. The DN is 
going to be constructed from (usually) the cn or uid attribute. The user 
will want to type in the cn/uid in an entry box, but then may realize 
that they made a typo and need to correct the cn/uid. We don't want to 
prevent them from doing this?

>> For attribute, the rationnal is that one replace attribute by a new 
>> one most of the time, and it's much easier to deal with immutable 
>> attribute - that's one of the aspect of UnboundId SDK that I prefer.
> Inside the server, having immutable Attribute is not really a problem. 
> From the client POV, I'm not convinced...

I totally agree. Client apps are very different to the server. 
Interestingly most of the pain we had with the immutable Attribute API 
in the server was in client apps such as LDIF tools and unit tests (most 
unit tests are like mini client apps).


View raw message