directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <enriqu...@gmail.com>
Subject Re: [ApacheDS] Mini-roadmap for protocol work
Date Sat, 29 Sep 2007 23:57:43 GMT
On 9/29/07, Alex Karasulu <akarasulu@apache.org> wrote:
> What are your motives for these changes?

My motivation is that I still believe in the idea of a combined "realm
controller" and, since a number of issues have been raised over the
last couple months, each of which I agree with, I would like to
address them in an effort to make the protocols easier for people to
work with.

> What are the benefits?

The benefit of test cases is that it should make it easier for people
to get into working with the protocols.  It also makes it easier for
changes to not cause regression.

The benefit to removing the chains, as succinctly noted previously by
you and Emm, is that reading the code and using a debugger is
improved.

The benefit of making the pre-auth verifiers pluggable is flexibility.
 We can currently only add one verifier at the class-loading point,
and Kerberos (the specs) supports numerous pre-auth types.

Enrique


> 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