You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Enrique Rodriguez <en...@gmail.com> on 2007/09/30 00:07:23 UTC
[ApacheDS] Mini-roadmap for protocol work
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
Re: [ApacheDS] Mini-roadmap for protocol work
Posted by Enrique Rodriguez <en...@gmail.com>.
On 9/29/07, Alex Karasulu <ak...@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
> >
>
>
Re: [ApacheDS] Mini-roadmap for protocol work
Posted by Alex Karasulu <ak...@apache.org>.
What are your motives for these changes?
What are the benefits?
Alex
On 9/29/07, Enrique Rodriguez <en...@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
>
Re: [ApacheDS] Mini-roadmap for protocol work
Posted by Emmanuel Lecharny <el...@gmail.com>.
> One note for Kerberos and Changepw: we'll need to have our own client
> libraries. These are mostly done, I would say in an alpha quality.
> NTP and DNS have client libraries we can use for tests. So, after
> DNS, we should revisit our client-side support for Kerberos and
> Changepw.
Clients need to be reviewed from scratch : they have not been upgraded
when we released 1.5.1
Tests for kerberos and kerberos clients are still two different
matters. We may have kerberos clients, but we _must_ have kerberos
tests. I have added a full bunch of PDU decoding tests in the kerberos
branch (this is why it takes so long to modify the code), but ut's not
enough.
Of course, having both tests and client is the must...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS] Mini-roadmap for protocol work
Posted by Enrique Rodriguez <en...@gmail.com>.
On 9/30/07, Stefan Zoerner <st...@labeo.de> wrote:
> Emmanuel Lecharny wrote:
>
> > for ( project in {DNS, NTP, DHCP, ChangePW, Kerberos} do
> > 1) Add some doco on confluence
> > 2) Clean the chain
> > 3) Add some tests
> > done
OK, I'll get going with DNS. I was in the middle of Kerberos tests so
I'll wrap-up some pre-auth tests then get on with DNS.
One note for Kerberos and Changepw: we'll need to have our own client
libraries. These are mostly done, I would say in an alpha quality.
NTP and DNS have client libraries we can use for tests. So, after
DNS, we should revisit our client-side support for Kerberos and
Changepw.
Enrique
Re: NTP integraion test added (was Re: [ApacheDS] Mini-roadmap for
protocol work)
Posted by Stefan Zoerner <st...@labeo.de>.
Hi Enrique!
Enrique Rodriguez wrote:
> This is a really nice test. In particular, it fills a gap between
> unit tests and the integration tests in server-unit, providing full
> server tests, including codecs. The tests I added for Kerberos tested
> at the IoHandler level and thus did not test the codecs. I will start
> to use something more like what Stefan worked out for the other
> protocols.
Thanks for the feedback.
> One issue, because this came up earlier this summer, is that when you
> get the loopback address, the best practice is to use 'null' as the
> hostname. 'null' will explicitly return the loopback address and
> avoid any issues with misconfigured hosts files that could cause the
> tests to fail. I've tested this on Sun and IBM and it should work
> given a read of Harmony source.
I have adjusted as you suggested:
...
InetAddress localhost = InetAddress.getByName( null );
...
And it works at least in my environment within Maven and Eclipse 3.2
with Sun JDK. Thanks for the hint,
Stefan
Re: NTP integraion test added (was Re: [ApacheDS] Mini-roadmap for protocol work)
Posted by Enrique Rodriguez <en...@gmail.com>.
On 9/30/07, Stefan Zoerner <st...@labeo.de> wrote:
> Emmanuel Lecharny wrote:
> >> * Should I create the tests in Big Bang or the 1.5 trunk?
> >
> > Add them in trunk, because we need them in trunk, but as we will merge
> > them with bigbang and the way out, at the end of the day, it makes no
> > difference...
>
> Thanks Emmanuel!
>
> I have added a simple integration test for the NTP server here
> http://svn.apache.org/viewvc?view=rev&revision=580746
This is a really nice test. In particular, it fills a gap between
unit tests and the integration tests in server-unit, providing full
server tests, including codecs. The tests I added for Kerberos tested
at the IoHandler level and thus did not test the codecs. I will start
to use something more like what Stefan worked out for the other
protocols.
One issue, because this came up earlier this summer, is that when you
get the loopback address, the best practice is to use 'null' as the
hostname. 'null' will explicitly return the loopback address and
avoid any issues with misconfigured hosts files that could cause the
tests to fail. I've tested this on Sun and IBM and it should work
given a read of Harmony source.
>From the javadocs:
"If the host is null then an InetAddress representing an address of
the loopback interface is returned. "
Enrique
Re: NTP integraion test added (was Re: [ApacheDS] Mini-roadmap for protocol work)
Posted by Emmanuel Lecharny <el...@gmail.com>.
> I have added a simple integration test for the NTP server here
> http://svn.apache.org/viewvc?view=rev&revision=580746
Great !
> I will continue to add tests, but have to dive into the implementation
> first ... And my NTP knowledge has to improve as well ...
Yes, I understand. This is why it's so important that the one who
initially implement the code add some tests to help other ones to get
into the code easily.
Thanks a lot for your great work, Stefan !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: NTP integraion test added (was Re: [ApacheDS] Mini-roadmap for protocol work)
Posted by Alex Karasulu <ak...@apache.org>.
This is great Stefan. I'm really excited to see people digging into these
other protocols.
I'm sure Enrique will help out any way he can to assist you.
Thanks,
Alex
On 9/30/07, Stefan Zoerner <st...@labeo.de> wrote:
>
> Emmanuel Lecharny wrote:
> >> * Should I create the tests in Big Bang or the 1.5 trunk?
> >
> > Add them in trunk, because we need them in trunk, but as we will merge
> > them with bigbang and the way out, at the end of the day, it makes no
> > difference...
>
> Thanks Emmanuel!
>
> I have added a simple integration test for the NTP server here
> http://svn.apache.org/viewvc?view=rev&revision=580746
>
> It simply starts it up in the setup method and checks the current time
> with the Apache Net NTP client (class NTPUDPClient).
>
> I will continue to add tests, but have to dive into the implementation
> first ... And my NTP knowledge has to improve as well ...
>
> Greetings, Stefan
>
>
>
>
>
NTP integraion test added (was Re: [ApacheDS] Mini-roadmap for protocol
work)
Posted by Stefan Zoerner <st...@labeo.de>.
Emmanuel Lecharny wrote:
>> * Should I create the tests in Big Bang or the 1.5 trunk?
>
> Add them in trunk, because we need them in trunk, but as we will merge
> them with bigbang and the way out, at the end of the day, it makes no
> difference...
Thanks Emmanuel!
I have added a simple integration test for the NTP server here
http://svn.apache.org/viewvc?view=rev&revision=580746
It simply starts it up in the setup method and checks the current time
with the Apache Net NTP client (class NTPUDPClient).
I will continue to add tests, but have to dive into the implementation
first ... And my NTP knowledge has to improve as well ...
Greetings, Stefan
Re: [ApacheDS] Mini-roadmap for protocol work
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 9/30/07, Stefan Zoerner <st...@labeo.de> wrote:
> Emmanuel Lecharny wrote:
>
> > for ( project in {DNS, NTP, DHCP, ChangePW, Kerberos} do
> > 1) Add some doco on confluence
> > 2) Clean the chain
> > 3) Add some tests
> > done
>
> I volunteer to do the docs and tests for NTP. I have already started
> with tests in order to learn how the protocol providers work, and NTP is
> the easiest one. I was able to create a JUnit integration test with
> Commons-Net NTP client, for instance.
That's just great ! The more tests we will have, the better. Also if
you get a grip on the code, that means the community is building up :)
>
> Perhaps Enrique can concentrate on the more complex and important
> protocols like ChangePW. The only thing I need is a code review by
> Enrique for the tests and the configuration documentation afterwards.
You'd better try to work together on NTP to be sure you don't miss
anyting important then. Use the ML for any question, so that everyone
will have the possibility to share your questions and answers.
I don't thing it will take to much of Enrique's time, so he can move
on changePw tests and doco.
>
> There are two questions I faced yesterday:
> * Is JUnit 4 now the default for tests (so: Should I use it for new tests)?
The asnwer is yes : we have bundled all the maven project with JUnit4.
It's not a big change, as previous test are still working well, but it
brings some cool new features like annotations. (I know, syntaxic
sugar, but anyway ;)
> * Should I create the tests in Big Bang or the 1.5 trunk?
Add them in trunk, because we need them in trunk, but as we will merge
them with bigbang and the way out, at the end of the day, it makes no
difference...
Thanks a lot Stefan !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS] Mini-roadmap for protocol work
Posted by Stefan Zoerner <st...@labeo.de>.
Emmanuel Lecharny wrote:
> for ( project in {DNS, NTP, DHCP, ChangePW, Kerberos} do
> 1) Add some doco on confluence
> 2) Clean the chain
> 3) Add some tests
> done
I volunteer to do the docs and tests for NTP. I have already started
with tests in order to learn how the protocol providers work, and NTP is
the easiest one. I was able to create a JUnit integration test with
Commons-Net NTP client, for instance.
Perhaps Enrique can concentrate on the more complex and important
protocols like ChangePW. The only thing I need is a code review by
Enrique for the tests and the configuration documentation afterwards.
There are two questions I faced yesterday:
* Is JUnit 4 now the default for tests (so: Should I use it for new tests)?
* Should I create the tests in Big Bang or the 1.5 trunk?
Thanks in advance,
Stefan
Re: [ApacheDS] Mini-roadmap for protocol work
Posted by Enrique Rodriguez <en...@gmail.com>.
On 9/29/07, Alex Karasulu <ak...@apache.org> wrote:
> On 9/29/07, Enrique Rodriguez <en...@gmail.com> wrote:
> > (CES 2008).
>
> What's CES stand for? I'm just ignorant.
Consumer Electronics Show
Enrique
Re: [ApacheDS] Mini-roadmap for protocol work
Posted by Alex Karasulu <ak...@apache.org>.
On 9/29/07, Enrique Rodriguez <en...@gmail.com> wrote:
>
> (CES 2008).
What's CES stand for? I'm just ignorant.
Alex
Re: [ApacheDS] Mini-roadmap for protocol work
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Enrique,
On 9/30/07, Enrique Rodriguez <en...@gmail.com> wrote:
> On 9/29/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> > ...
> > May I suggest that you just do it in a slightly different order ?
>
> Unfortunately you not only changed the order but you introduced
> substantial scope creep. While all the changes you suggest are valid,
> I have to package them such that I can actually complete them in OCT.
The scope I'm targeting is the Apache Directory project as a whole. I
not only want a working server, but I want it documented, and
supported. The only way to get it supported is by sharing the code
with the community, which means tests, document and support by more
than one committer. The time frame doesn't matter at all, and if we
get it by december, it's fine. Remember that we decide as a community
what is the good time frame for the project, and we currently are
working on a 2.0 roadmap, which has been agreed on.
>
> > for ( project in {DNS, NTP, DHCP, ChangePW, Kerberos} do
>
> I specifically left out NTP and DHCP, mostly due to time limitations,
> though secondarily since they don't have IoHandlerChain's and because
> they seem to be lower priority given the queries we get. Certainly
> they are valid concerns, though.
They are, because they are part of the project. Otherwise, we will
have to sandbox all those projects at some point, because we can't
afford users to post questions which don't get answers.
>
> > 1) Add some doco on confluence
>
> Everyone of these protocols (except DHCP, IIRC) has docs in the AUG.
> Any thoughts on what else you'd like to see?
A quick look at those pages just show they are by far not completed.
I'm specifically talking about Kerberos.
>
> > 2) Clean the chain
>
> Removing the chains is an orthogonal concern. By this, I mean I can
> remove all the chains at once, since it is a similar operation,
> independent of protocol behavior. I can probably remove the SASL one,
> but I left it out since it is more in the midst of "bigbang" changes.
We will handle the SASL chain removal. I still think that it's better
to remove chains one by one, test them, and move to the next one.
'orthogonal' work usually is a source of problem, because as we have
no tests at all, we have no way to check that something has been
missed (and trust me, I have done this mistake more than often, I know
what I'm talking of:)
>
> > 3) Add some tests
> > done
>
> > ...
> > The idea is to clean the simplest protocols first, and to get me into
> > the last loop when starting with Kerberos. I have still a hell loyt of
> > work to do on the kerberos branch, and I really want to do it with
> > you.
>
> OK. I am shooting for next month. Something to consider is that if
> you want to better support users, digging into the code may not be the
> most effective use of time. Most user questions will be at a higher
> level, pertaining to configuration of the provider and how to
> integrate Kerberos with Linux, Windows, and various services. I'm
> looking forward to the ASN.1 boost, but, to be perfectly honest, its
> not going to be as valuable to users as getting interop scenarios
> working.
Better support does not mean digging the code. It means being able to
understand what is going on, and also fix some bugs. How possibly can
you tell that a user problem is due to a bug in kerberos or a bug in
the server if you don't have a clear vision of what is going on inside
the guts of the kerberos code? And we also have two kinds of users :
what I call normal users and developpers who may be interested at
using our code.
I think you are also missing a very important point : the ASF has a
clear target : create a community around some project. The code is
nothing if nobody can 'support' it. It's not only about users, it's
about new committers. How can we gather new committers if nobody can
support them?
Now, regarding the present code, my effort was exactly aiming this
target : being able to understand what has been put into the kerberos
server, and leverage what we have done into ApacheDS to avoid a
duplication of effort. Using two differnt libs to do the same thing
means that a new committer will have to spend twice as much time to
handle the code. Not exactly a good idea.
>
> > - you can add your mini-roadmap into the main roadmap
> > (http://cwiki.apache.org/confluence/display/DIRxPMGT/2.0+Roadmap), so
> > that everyone will have a clear visibility about your progression
> > (it's a matter of when we will be able to release : as you can see, we
> > are now 11 working on the project, and we must be much more 'serious')
>
> Will do, once I get some sense as to whether it's "approved."
Whatever work done in this project will be approved considering it's
consistent with :
1) "the Apache way" : http://www.apache.org/dev/committers.html#apache-way
The first point is really important : "collaborative software development"
2) The schedule defined by the PMC
> > Btw, if you have to work on a new external project, it would be cool
> > to tell us so we can define a deadline for some of you assigned tasks,
> > to be able to define the 2.0 release content.
>
> I'd like to wrap-up any work up by the end of October.
Well, then, we will have to setup a compatible roadmap for this work.
If it's not compatible with ADS roadmap, we will have to wait. There
are a lot of thing to do in one single month... Let's discuss that on
another thread.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS] Mini-roadmap for protocol work
Posted by Enrique Rodriguez <en...@gmail.com>.
On 9/29/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> ...
> May I suggest that you just do it in a slightly different order ?
Unfortunately you not only changed the order but you introduced
substantial scope creep. While all the changes you suggest are valid,
I have to package them such that I can actually complete them in OCT.
> for ( project in {DNS, NTP, DHCP, ChangePW, Kerberos} do
I specifically left out NTP and DHCP, mostly due to time limitations,
though secondarily since they don't have IoHandlerChain's and because
they seem to be lower priority given the queries we get. Certainly
they are valid concerns, though.
> 1) Add some doco on confluence
Everyone of these protocols (except DHCP, IIRC) has docs in the AUG.
Any thoughts on what else you'd like to see?
> 2) Clean the chain
Removing the chains is an orthogonal concern. By this, I mean I can
remove all the chains at once, since it is a similar operation,
independent of protocol behavior. I can probably remove the SASL one,
but I left it out since it is more in the midst of "bigbang" changes.
> 3) Add some tests
> done
> ...
> The idea is to clean the simplest protocols first, and to get me into
> the last loop when starting with Kerberos. I have still a hell loyt of
> work to do on the kerberos branch, and I really want to do it with
> you.
OK. I am shooting for next month. Something to consider is that if
you want to better support users, digging into the code may not be the
most effective use of time. Most user questions will be at a higher
level, pertaining to configuration of the provider and how to
integrate Kerberos with Linux, Windows, and various services. I'm
looking forward to the ASN.1 boost, but, to be perfectly honest, its
not going to be as valuable to users as getting interop scenarios
working.
> - you can add your mini-roadmap into the main roadmap
> (http://cwiki.apache.org/confluence/display/DIRxPMGT/2.0+Roadmap), so
> that everyone will have a clear visibility about your progression
> (it's a matter of when we will be able to release : as you can see, we
> are now 11 working on the project, and we must be much more 'serious')
Will do, once I get some sense as to whether it's "approved."
> - We will also clean the chain into SASL, because we have clear
> problems with it (not sure it's already in the roadmap, but we will
> add it).
Valid concern but scope creep.
> Btw, if you have to work on a new external project, it would be cool
> to tell us so we can define a deadline for some of you assigned tasks,
> to be able to define the 2.0 release content.
I'd like to wrap-up any work up by the end of October. I have a new
deadline of early JAN (CES 2008). I don't exactly have downtime right
now; I am simply taking away from any room for error I have later in
the year.
Enrique
Re: [ApacheDS] Mini-roadmap for protocol work
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Enrique,
seems to be a pretty neat roadmap.
May I suggest that you just do it in a slightly different order ?
for ( project in {DNS, NTP, DHCP, ChangePW, Kerberos} do
1) Add some doco on confluence
2) Clean the chain
3) Add some tests
done
(I don't really know if DHCP won't be sandboxed at some point, but NTP
will remain in the server, because it's needed for Kerberos.)
The idea is to clean the simplest protocols first, and to get me into
the last loop when starting with Kerberos. I have still a hell loyt of
work to do on the kerberos branch, and I really want to do it with
you.
Some more points :
- for doco, Christine and Stefan (Z) are the peeps to work with.
- you can add your mini-roadmap into the main roadmap
(http://cwiki.apache.org/confluence/display/DIRxPMGT/2.0+Roadmap), so
that everyone will have a clear visibility about your progression
(it's a matter of when we will be able to release : as you can see, we
are now 11 working on the project, and we must be much more 'serious')
- We will also clean the chain into SASL, because we have clear
problems with it (not sure it's already in the roadmap, but we will
add it).
- we will have to work on kerberos together, and it will take time, so
be patient, because there are many things we will change in the server
itself. However, I think we will be much more efficient together than
each of us alone.
- This may differ the PKINIT integration into the trunk, but it's not
really a big deal, if we can have a clean place to inject it.
Btw, if you have to work on a new external project, it would be cool
to tell us so we can define a deadline for some of you assigned tasks,
to be able to define the 2.0 release content.
Thanks !
On 9/30/07, Enrique Rodriguez <en...@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
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com