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: pass (asf.osuosl.org: domain of aok123@bellsouth.net designates
 205.152.59.68 as permitted sender)
Message-ID: <435E4A8F.5050006@bellsouth.net>
Date: Tue, 25 Oct 2005 11:09:03 -0400
From: Alex Karasulu <aok123@bellsouth.net>
User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923)
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [ApacheDS][Release] Remaining JIRA issues for 0.9.3 roadmap
References: <435DE21E.3080603@bellsouth.net>
 <1130232181.7949.18.camel@portable>
In-Reply-To: <1130232181.7949.18.camel@portable>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Emmanuel Lecharny wrote:

>Yo, 
>
>  
>
>>[2] http://issues.apache.org/jira/browse/DIREVE-163 (Emmanuel)
>>
>>2 - JPEG corruption issue: this is an ugly one so we'll need status on it
>>[2] I think is involved and can be pushed out if it's not going to be done 
>>within the next 24 hours.
>>    
>>
>
>This is really a simple but ugly one. After more or lmess two month of
>"evaluation", here is its status :
>- the reason why Jpeg (and any other binary element) are not well
>handled is that the decoders are transforming every value to a String.
>This is, of course, not the right thing to do
>- it leads to another correlated problem, Strings are encoded as simple
>Strings, not UTF-8 Strings. This is also a problem
>- then, we need to control the HR tags (Human Readable) into the
>SchemaService methods before doing any transformation of any value that
>are OctetString (see RFC 2251)
>- Last, but not least, we have to deal with DN normalization, if any
>binary attribute is to be used - I bet this is possible -. As those
>attributes will be encoded with a # followed by the hexadecimal String,
>we have to check that this attribute is binary or not.
>
>Not to mention that a huge regression test has to be done...
>
>I've currently created a new branch (called xxx-utf8) to deal with all
>those problems, and the impact on the code will be huge.
>
>I really don't think that it will be a simple and easy patch, so I just
>suggest that this 0.9.3 release should be delivered without it.
>  
>
No problem we'll just push this over to 0.9.4.

Alex