james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Avalon dependance in mailets
Date Tue, 07 Jan 2003 15:29:16 GMT

Danny Angus wrote:
> 
>  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.

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.

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                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


Mime
View raw message