Mailing-List: contact api-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: api@directory.apache.org
Received-SPF: pass (nike.apache.org: domain of fanf42@gmail.com designates
 209.85.219.217 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=a3hURlnahLozgXdfPCOw0iJIzMEuxKgBwVnAn6f4bt3JSQ7Y5FmzBFnUDrrUM4bZsF
         dqjC7KGrrEeQ+nGYYDbwE/Ls4lXAjiHY5z3nXkFELXTP6Dq/S0NMUnFAy6MCrN9qwziC
         6cUwg1Agpltje66Viq4oesGqpvxfx7JEWiYok=
Message-ID: <4B4DB6A7.6080308@gmail.com>
Date: Wed, 13 Jan 2010 13:03:51 +0100
From: Francois <fanf42@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr;
 rv:1.9.1.5) Gecko/20091204 Lightning/1.0pre Thunderbird/3.0
MIME-Version: 1.0
To: api@directory.apache.org
Subject: Re: [DN] Existing API review
References: <4B4C7948.3000503@gmail.com> <4B4DAD6E.4040204@sun.com>
In-Reply-To: <4B4DAD6E.4040204@sun.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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