Danny Angus wrote:
Errr, what about logging? I mean that every service that a mailet uses that are not part of the mailet API can potentially be a portability breaker.Nicola Ken Barozzi wrote:This makes me think...Its a thought provoking topic! I wrote another reply to this mail, but by the end of it I'd changed my mind, here's version 2 :-)Essentially the Mailet API won't thus provide portability of mailets between servers, just a common API, right?Actually the work I've been doing is supposed to this so ..Meaning that I cannot simply get a mailet written from James and simply pop it into XMailServer and hope it to run, right?That is not correct *unless* your mailet uses Avalon via James to get database connections, in which case your mailet will not be portable. In all other cases it will be.
Not that I see this as a bad thing, in fact I start to understand the reasoning behind a simple API.
This could be a strength and a weekness. Strength because it's easier to learn, implement and to keep focused in development . Weekness because it's not made to make completely portable mailets. So what about doing a Mailet spec as defined above and define an additional Avalon Mailet profile, that James could use, to define other aspects like logging, get db connections, etc?We discussed this a while ago, and I argued that we should keep the API as clean of dependancies as we can. The db issue is really only relevant for the portability of James mailets, it is possible to write portable db access mailets by managing connections independantly of James.
Yup.
:-)If what you are suggesting is that we should build a portable 100% Mailet API compliant framework which would itself manage these services for any mailets written to use it then I agree.
Of course, I see this Mailet API compliant framework as
Mailet API + Avalon API
IMHO if we say that James mailets are just Avalon Components that use Mailet API, then there is no need to define anything else.
It would have to be compact, I have a vision of the Mailet API being used in client software for mail filtering and similar tasks.
Yes.
It would also have to be deployable either as a runtime dependance or as a simple wrapper for single mailets.
Cool.
One further option might be to include processors in the API specification and create a distributable processor which could offer services to the mailets it contained. At the end of the day, though, if we assume that not all mailet containers will be capable of providing JDBC connectivity for some reason then mailets using JDBC will have their portability restricted no matter what we do.
Yes, that's what I came to think too.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
