Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <474B90D8.2070800@jonanddeb.net>
Date: Mon, 26 Nov 2007 20:36:56 -0700
From: Jon Roberts <jon@jonanddeb.net>
Reply-To: man@mentata.com
User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720)
MIME-Version: 1.0
To: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= <michael@stroeder.com>
CC: Marc Boorshtein <mboorshtein@gmail.com>,
        Apache Directory Developers List <dev@directory.apache.org>,
        openldap-devel@openldap.org
Subject: Re: Empty DN ("") String Value?
References: <800df6390711251259se74fb63h41157744e03d70ea@mail.gmail.com>
 <474AB152.2030907@stroeder.com>
In-Reply-To: <474AB152.2030907@stroeder.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Michael Ströder wrote:
> Marc Boorshtein wrote:
>>I wanted to get an opinion from the other java ldap projects.  Should
>>the toString() method of a class that represents a DN return null or
>>an empty string?  I would think an empty string but JLDAP returns
>>null.  Anyone have an opinion on the matter?

Not a strong one, since I don't make use of DN.toString(). In my view 
the DN utility class is for deconstructing, analyzing, and comparing 
non-trivial distinguished names... I invariably have the string version 
to begin with.

> It really depends on what you want to express. Note that "" represents
> the rootDSE or root naming context. So "" would reference something
> existing or well-defined. IMHO NULL (or None in Python) would better
> signal something undefined or none-existing.

This was my first thought, but according the source as I read it these 
cases would not be distinct: if there are no parent RDNs superior to the 
entry reflected in the represented DN, toString() will return null.

Since there is a no-argument constructor DN(), perhaps the original 
thinking was that null and the rootDSE "" are synonymous. On the other 
hand, the existence of this constructor makes as much sense to me as the 
redundant addRDN() and addRDNToFront() methods (ie. none at all). I 
suppose *somebody* may want to build a DN instance iteratively, but I 
would consider it easier to do so concatenating strings for submission 
to the more relevant constructor with argument.

This exercise in software archeology underscores a major reason I think 
JLDAP is latent: a lot of cruft but nobody of original authorship to 
explain or clean it up. As for the rest of us, if nobody touches it 
nobody breaks it, so there it sits. My 2c.

Jon Roberts
www.mentata.com