> That is why I am agreeing with you to replace it.

OK, point of agreement.  You both think that the authentication mechanism is
fundamentally flawed at the architecture level, and should be replaced.  :-)

> It may not be the best mechanism, but AuthServiceFactory fixes the problem
> you found and it is better than coupling auth stuff inside handler.

I believe that Peter feels that what he's done is a quick hack to make it
work, and since both of you agree that the whole thing should be ripped out,
tossed, and replaced as soon as 2.1 is closed he'd rather go with something
that he's been testing rather than start again right now with an
AuthServiceFactory that he expects would ALSO be ripped, tossed and
replaced.

If I am reading both of you correctly, then his point of view makes some
sense.  Rather than invest the time in AuthServiceFactory now, with the
intent of replacing it anyway, why not go out the door with his code (if it
works), and then start the discussion about proper design?

> I'll make sure AuthService issue is corrected before release. The change
> delta will be smaller with AuthServiceFactory from current codebase.

My personal view is that we're getting down to the short straws on the 2.1
release, and I'm getting very antsy about changes.  You get a vote, I don't,
but there have been several bugs introduced recently that came from innocent
little fixes and code refactoring.  Bugs happen.  The only way to guarantee
that you don't introduce a new one is not to change code.  So unless we have
a bug to fix, I'd just as soon not change code.  Peter still has connection
handling changes that he wants to check in, which makes me very nervous at
this late date.

> We have so far talked about what should not be. Let us talk about what
> should be the right way. ideas...

The sense that I get from Peter's messages is that he wants to focus on
getting 2.1 out, and not lose his focus by getting into tangential
discussion on future architecture.  This is similar to why Danny wants to
put off discussion about the Mailet API until later, and why I'd like him to
put off discussing the store interface, too.  Because we all want to be able
to participate and discuss those, but right now we're trying to focus on the
current codebase.

        --- Noel


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to