----- Original Message -----
From: "Noel J. Bergman" <[EMAIL PROTECTED]>
> Harmeet,
>
> I have reviewed your proposal. Here is my quick take on it, as a proposed
> code change:
>
> - AuthState +1
>
> This just takes existing data from the handler, and encapsulates it as a
> Java Bean.
>
> - AuthService +1
>
> This simply takes two methods from the handler, and separates them as an
> interface.
>
> - AuthServiceImpl conditional
>
> You have eliminated the stateful problems, but it remains to be seen what
> you do with this class. As I understand it, an instance of AuthService
> would be passed to the NNTPHandler through its service specific
> configuration object.
>
> Apparently, Peter objects to exposing AuthService to other James
components,
> so if this is a Block in james-assembly.xml, he has stated that he intends
> to veto it.
> I'm curious to see what other folks have to say. However, if
> you hide the AuthService inside NNTPServer, e.g.,
>
> NNTPServer() { ... authService = new AuthServiceImpl(); ... }
> compose(...) { ... authService.compose(...); ... }
> configure(...) { ... authService.configure(...); ... }
> enableLogging(...) { super(logger); setupLogger(authService); ... }
>
> or equivalent means, then that might address the objections that I have
read
> so far. All of this presumes, of course, that the code works, otherwise
it
> would need to be fixed.
>
I was thinking along similar lines after the last offline conversion,
however wasn't sure if I should do it right away or defer when the email
flow started.
I was also thinking that configuration can be centralized, but the actual
code
can exist as a service. This would give ease of configuration and
pluggability.
> However, before you invest much more into this effort, consider the
> following.
>
>
> As I understand it the primary purpose for the AuthService is that you
want
> to decouple handlers from repositories: (a) basically don't trust the
> repository interface, and (b) you want to allow an LDAP or Radius
> authentication server to be used. If someone deploying James has that
need,
> it can be addressed. In the meantime, you can easily isolate the
> AuthService inside the NNTPServer, allowing NNTPHandler to remain entirely
> unchanged, which is your primary goal.
>
> One reason for limiting the investment of time and energy into AuthService
> is that if JAAS ends up being used in v3, then it is likely that
AuthService
> would disappear again forever, since JAAS has its own means by which
service
> providers are installed.
>
JAAS is possible and a good idea. But JAAS may not be overkill for some.
A simple authentication service that allows folks to plugin authentication
without understanding Avalon User Respositories may be valuable. Implement 2
methods to plugin authentication seems simple to explain to anyone who may
need to do this.
AuthService is also minor change on the current code. It has been there but
stateful and broken so in essence it is a fix more than anything else.
Regd. effort - has already been done. I was trying to write automated
regression tests
to verify things better for now and future.
I prefer that we defer this change and any scheduler changes
till 2.1 is complete. I would like to minimize chances of the kind of
interaction that has gone on recently.
> Your thoughts, Kind Sir?
Hopefully someday I will be as kind and graceful as you. :-)
Harmeet
--
To unsubscribe, e-mail: <mailto:james-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@;jakarta.apache.org>
