[ApacheDS][Release] Remaining JIRA issues for 0.9.3 roadmap

[Alex Karasulu <ao...@bellsouth.net>]

Hiya,

The following issues still remain for the 0.9.3 release on the JIRA 
roadmap.  Here's a quick list with the assignee working on it:

[0] http://issues.apache.org/jira/browse/DIREVE-164 (Trustin)
[1] http://issues.apache.org/jira/browse/DIREVE-278 (Stefan)
[2] http://issues.apache.org/jira/browse/DIREVE-163 (Emmanuel)

My take on these issues:

0 - not worried about it since change can be made any time: we can push 
it out
1 - doco we could work on this for a while (perhaps dedicate some time 
before the release)
2 - JPEG corruption issue: this is an ugly one so we'll need status on it

Let's give another day to doco [1].  [0] can be done anytime.  [2] I 
think is involved and can be pushed out if it's not going to be done 
within the next 24 hours.

I have rolled up a distro SNAPSHOT and put it into my home directory for 
evaluation.  Take a look and let me know what you think.  Last minute 
changes are not going to change what you see here by much.

Oh and FYI here's a summary of the changes in 0.9.3 since the last release:

http://diharque.notlong.com

SNAPSHOT Distros
--------------------------------

 o http://www.apache.org/~akarasulu/dist/apacheds-0.9.3-SNAPSHOT-src.tar.gz
 o http://www.apache.org/~akarasulu/dist/apacheds-0.9.3-SNAPSHOT-src.zip

 o http://www.apache.org/~akarasulu/dist/apacheds-0.9.3-SNAPSHOT.tar.gz
 o http://www.apache.org/~akarasulu/dist/apacheds-0.9.3-SNAPSHOT.zip

If all looks good after tomorrow we'll kick off a vote and hopefully 
release 0.9.3 at the end of the week.

Cheers,
Alex

Re: [ApacheDS][Release] Remaining JIRA issues for 0.9.3 roadmap

[Alex Karasulu <ao...@bellsouth.net>]

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

Re: [ApacheDS][Release] Remaining JIRA issues for 0.9.3 roadmap

[Emmanuel Lecharny <el...@gmail.com>]

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.

PS: I learnt the hard way that this kind of patch need a very deep
knowledge of the whole system, this is one of the reason it took so
long. The positive point is that I understand much more parts or
ApacheDS, but this is still a rough trip ;). We really need more people
being involved in the guts of ApacheDS !

-- Emmanuel

Re: [ApacheDS][Release] Remaining JIRA issues for 0.9.3 roadmap

[Alex Karasulu <ao...@bellsouth.net>]

Trustin Lee wrote:

> Hi Alex,
>
> 2005/10/25, Alex Karasulu <aok123@bellsouth.net 
> <ma...@bellsouth.net>>:
>
>     [0] http://issues.apache.org/jira/browse/DIREVE-164 (Trustin)
>     My take on these issues:
>
>     0 - not worried about it since change can be made any time: we can
>     push
>     it out
>
>
> I've found our implementation (apacheds-core) throws an 
> LdapNamingException with LDAP-specific error codes such as 
> ALIASPROBLEM.  I thought we can stop all classes from throwing 
> LdapNamingException and make them throw NamingException instead, and 
> then ExceptionService can convert them to corresponding 
> LdapNamingExceptions 1:1.  But it's not 1:1 right now.  So I cannot 
> divide ExceptionService into IntegrityService and ExceptionService 
> currently.
>
> I guess we need to standardize which type of exceptions we should 
> throw for consistency.  NamingException or LdapNamingException?  I 
> think LdapNamingException is the way to go.
>
> Once decided, I'll modify the core ASAP.

Well keep in mind that this is internal refactoring so it can be done 
anytime.  No need to rush on this.  We can push this up to next release.

Alex

Re: [ApacheDS][Release] Remaining JIRA issues for 0.9.3 roadmap

[Trustin Lee <tr...@gmail.com>]

2005/10/25, Trustin Lee <tr...@gmail.com>:
>
> Hi Alex,
>
> 2005/10/25, Alex Karasulu <ao...@bellsouth.net>:
> >
> > [0] http://issues.apache.org/jira/browse/DIREVE-164 (Trustin)
> > My take on these issues:
> >
> > 0 - not worried about it since change can be made any time: we can push
> > it out
>
>
> I've found our implementation (apacheds-core) throws an
> LdapNamingException with LDAP-specific error codes such as ALIASPROBLEM. I
> thought we can stop all classes from throwing LdapNamingException and make
> them throw NamingException instead, and then ExceptionService can convert
> them to corresponding LdapNamingExceptions 1:1. But it's not 1:1 right now.
> So I cannot divide ExceptionService into IntegrityService and
> ExceptionService currently.
>
> I guess we need to standardize which type of exceptions we should throw
> for consistency. NamingException or LdapNamingException? I think
> LdapNamingException is the way to go.
>
> Once decided, I'll modify the core ASAP.
>

I've marked DIREVE-164 as 'INVALID'.

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/

Re: [ApacheDS][Release] Remaining JIRA issues for 0.9.3 roadmap

[Trustin Lee <tr...@gmail.com>]

Hi Alex,

2005/10/25, Alex Karasulu <ao...@bellsouth.net>:
>
> [0] http://issues.apache.org/jira/browse/DIREVE-164 (Trustin)
> My take on these issues:
>
> 0 - not worried about it since change can be made any time: we can push
> it out


I've found our implementation (apacheds-core) throws an LdapNamingException
with LDAP-specific error codes such as ALIASPROBLEM. I thought we can stop
all classes from throwing LdapNamingException and make them throw
NamingException instead, and then ExceptionService can convert them to
corresponding LdapNamingExceptions 1:1. But it's not 1:1 right now. So I
cannot divide ExceptionService into IntegrityService and ExceptionService
currently.

I guess we need to standardize which type of exceptions we should throw for
consistency. NamingException or LdapNamingException? I think
LdapNamingException is the way to go.

Once decided, I'll modify the core ASAP.

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/