> The discussion is primariy comp sci pattern focused instead of usage
focused.
>From my end, I'm just trying to assure that Mailet authors will have common
and sufficiently rich interfaces to implement vendor-neutral Mailets. I am
not interested in an academic exercise. I look at each thing from the
perspective of "what do I need, as a developer."
> > compMgr =
> > getMailetContext().getAttribute(Constants.AVALON_COMPONENT_MANAGER);
> > MailStore mailstore =
> > compMgr.lookup("org.apache.james.services.MailStore");
> I think I'm missing the criticism of this approach. The mailet API is
> allowing you access to container specific features.
I was not criticizing. I was simply pointing out that this is how the
current Mailet API supported what you had asked me, namely what to do about
mailets that want something, e.g., a repository, that is not supported on a
specific container. I then further noted that (since this mechanism uses
Avalon Frameworks), that Best Practices with the Avalon Frameworks
programming model would work a bit differently, and I gave an example.
> What you call future-proofing, I would call adding a bunch of imports
> and implements for no benefit to someone as a non-interface A user.
Not sure I follow that ... can you illustrate? I do not believe that we are
saying the same thing at all.
> What logging capabilities does a mailing list need that log() doesn't
> support? How many listsoft or ezmlm admins look at their log files?
I look at the log files, for one. :-) And we've had at least 6 voices
raised asking for better control that just log().
> The storage issue is much more difficult. I honestly can't see how you
> standardize an API around tailored multiple applications. Start with
> the user repositories... I can think of half a dozen very different ways
> that a mailing list might work.
>From what you described, I can't think of a problem representing any or all
of the scenarios (not quoted) in a JNDI style node. More over, I think that
all of those items represented perfectly legitimate information that I
*WANT* to have available. Perhaps one problem is that a User is represented
as Bean with properties, when it should probably be more of a property table
(method-per-property vs keyed-access).
> And to some extent, we've tried to create a standard user repository
> API... it doesn't quite work though. The idea was to let a standard
> user repository API support POP3 logins, SMTP auth, mailing lists, and
> anything else.
See above for a suggestion on how the interface can be improved by opening
it up the range of storable attributes. Sort of a JNDI-lite, instead of
having to deal with the complexity of JNDI (I've written JNDI code,
including on the SPI side).
> Ahem... JSR 47 HAS produced a common API for logging. It's called
> java.util.logging.
True ... but it is neither in the Servlet API nor exposed to Mailets, which
was sort of the context of the discourse.
> Beware of the rotten tomatoes incoming from the Avalon developers. :)
Fair enough. :-) Apparently, though the Avalon Frameworks supports JSR 47.
> I guess I still don't see what you're suggesting that James +
> Avalon-framework doesn't already do.
Wait, I have not said that James + Avalon Frameworks doesn't do something!
I said that a Mailet API *WITHOUT* Avalon Frameworks is anemic, and that if
we don't specify how to fill the gaps (using the Avalon Frameworks is one
way), then those gaps will be filled with vendor-specific solutions, and
that is the thing that is unacceptable.
> You've got a mailet API... you've got composable, etc-able
> interfaces that you can get as servlet context attributes.
> You can log, you can store, and whatever else that the
> Avalon-framework is providing.
Exactly! And I want to be able to RELY upon that regardless of whose
container implementation I'm using. That's it exactly!
--- Noel [off to get some sleep before ENG v NGA in a few hours]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
