[ApacheDS] [SASL Branch] Shall we merge into trunk?

[Alex Karasulu <ak...@apache.org>]

Enrique,

I've been reviewing the sasl branch and it looks good but I have not
completed the whole thing
since the changes are extensive.  What ever I did not cover can be discusses
over time instead
of holding back a merge.

If there are no objections please feel free to merge this SASL branch into
the trunks.  Even if
we have some issues with things I'm sure we can rectify them later or
perhaps you can clarify
things more for us if we misunderstand your purpose.

Alex

Re: [ApacheDS] [SASL Branch] Shall we merge into trunk?

[Alex Karasulu <ak...@apache.org>]

On 5/21/07, Enrique Rodriguez <en...@gmail.com> wrote:
>
> On 5/21/07, Alex Karasulu <ak...@apache.org> wrote:
> > I've been reviewing the sasl branch and it looks good but I have not
> > completed the whole thing
> >  since the changes are extensive.  What ever I did not cover can be
> > discusses over time instead
> > of holding back a merge.
>
> Cool.  You mentioned noticing some re-org possibilities while in there
> and I noticed some refactorings, too.  However, they were outside the
> scope of SASL so I held off.  In particular, SessionRegistry is
> redundant since MINA will handle this for you.   However,
> SessionRegistry is used by that test GUI extended operation handler or
> else it would be trivial to refactor away.


Oh yeah this is also possible but I was thinking of other things.  No matter
tho we can discuss these after we get the merge completed.

Also, protocol-shared is slowing being emaciated so we can probably
> find homes for its code elsewhere and delete the module.


Ahh yes I saw this too.  Also I think we need to do away with using generic
JNDI
for the time being until we can re-write a better JNDI provider wrapper
because
of some shortfalls with the JNDI class implementations.  There are some
horrendous
bugs in the JNDI code from SUN that has plagued Emmanuel for months now.
But
we are seeing ways to fix these as we slowly clean somethings up.

Eventually I'd like to see us use a custom API since JNDI is not cutting it
now.  It
is seriously choking the architecture in the core and we need to do away
with it
temporarily until we can implement a better JNDI wrapper around the core
rather
than trying to integrate the core with JNDI.  Incidentally these changes
will better
isolate functionality and reduce the tight coupling we have in most packages
making
it easier to goto OSGi.  Again we can discuss these details later as we
evolve the
server core with small refactorings after this merge.

 The
> Kerberos-aware LDIF loader should be removed since it conflicts with
> the new and more capable KeyDerivationService.


Yes I figured this as well.  No need for it with the new interceptor.  Even
later
the interceptor will be replaced by triggers I imagine but it's too early to
discuss
that as well.

>  ...
> >  If there are no objections please feel free to merge this SASL branch
> into
> > the trunks.  Even if
> > we have some issues with things I'm sure we can rectify them later or
> > perhaps you can clarify
> > things more for us if we misunderstand your purpose.
>
> Yeah, it's definitely not set in stone.  Getting it into trunks will
> get more people to try out the config live and to hit it with
> SASL-capable clients.  BTW, was anybody able to test SASL clients with
> it?  It works solid for me but I hadn't heard from others.


I'm ashamed to admit that have not tried yet with anything other than
running
your test cases.  I will give it a try though perhaps after the merge.  I'm
sure
after the structures are in place if we run into some snag a fix will be
easily
applied if needed at all.

I will merge SASL after the 'kerberos-encryption- types' branch.  I
> want to test SASL GSSAPI with the KeyDerivationService and with AES
> and DES3.


That's good news.  Again keep me posted because I will wait on the merge
before
adding the HTTP service as I mentioned before.

Alex

Re: [ApacheDS] [SASL Branch] Shall we merge into trunk?

[Enrique Rodriguez <en...@gmail.com>]

On 5/21/07, Alex Karasulu <ak...@apache.org> wrote:
> I've been reviewing the sasl branch and it looks good but I have not
> completed the whole thing
>  since the changes are extensive.  What ever I did not cover can be
> discusses over time instead
> of holding back a merge.

Cool.  You mentioned noticing some re-org possibilities while in there
and I noticed some refactorings, too.  However, they were outside the
scope of SASL so I held off.  In particular, SessionRegistry is
redundant since MINA will handle this for you.   However,
SessionRegistry is used by that test GUI extended operation handler or
else it would be trivial to refactor away.

Also, protocol-shared is slowing being emaciated so we can probably
find homes for its code elsewhere and delete the module.  The
Kerberos-aware LDIF loader should be removed since it conflicts with
the new and more capable KeyDerivationService.

>  ...
>  If there are no objections please feel free to merge this SASL branch into
> the trunks.  Even if
> we have some issues with things I'm sure we can rectify them later or
> perhaps you can clarify
> things more for us if we misunderstand your purpose.

Yeah, it's definitely not set in stone.  Getting it into trunks will
get more people to try out the config live and to hit it with
SASL-capable clients.  BTW, was anybody able to test SASL clients with
it?  It works solid for me but I hadn't heard from others.

I will merge SASL after the 'kerberos-encryption- types' branch.  I
want to test SASL GSSAPI with the KeyDerivationService and with AES
and DES3.

Enrique