directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [ApacheDS] Mini-roadmap for protocol work
Date Sat, 29 Sep 2007 23:22:56 GMT
What are your motives for these changes?

What are the benefits?

Alex

On 9/29/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
>
> Hi, Directory developers,
>
> I'd like to continue addressing some "unfinished business" with the
> various protocols.  This is in an effort to address some issues raised
> in the past (and recently).  So, I put together a "mini-roadmap,"
> below, of items I think I can get to in OCT.  Much of this is internal
> refactoring, with only 1-2 touchpoints that we'll need to coordinate.
>
> The changes fall into roughly three categories:  chains, tests, and
> Kerberos pre-authentication.
>
> 1)  Regarding chains, I would like to remove the use of the
> IoHandlerChain's in DNS, Change Password, and Kerberos, in that order.
> DNS and Change Password should go easily.  Kerberos will go easily
> too, with the only consideration being any conflict with changes Emm
> has made and needs to merge in his Kerberos branch.
>
> 2)  Regarding tests, I've added a ton for Kerberos but I haven't gone
> and done the similar effort for DNS and Change Password.  Also,
> pre-auth coverage for Kerberos isn't very good.  Adding tests won't
> effect anybody's work, but I wanted to mention this because the tests
> will go hand-in-hand with removing the chains in #1.  Furthermore, I
> expect the tests for Kerberos pre-auth to occur (TDD) while I'm
> revamping pre-auth in #3.
>
> 3)  Regarding Kerberos pre-auth, I see this combining (a) tests with
> (b) the removal of the pre-auth, AS, and TGS IoHandlerChain's, (c) the
> refactoring of the class loader mechanism with a Spring configuration
> mechanism a la David's recent work, and (d) the addition of PKINIT as
> a new pre-auth mechanism.  Of course, PKINIT work will continue in my
> sandbox, but it makes sense to me to work on pre-auth all at once so
> I'll have my head around it all.  The only "end user" consideration
> here is that pre-auth configuration will be exposed, but since we can
> ship defaults that are unchanged from how it currently works no one
> should notice.
>
> I don't think any of this affects the current plans around the
> "bigbang" effort, but please give your thoughts on the above and I can
> get going with it pretty much immediately.
>
> Enrique
>

Mime
View raw message