james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter M. Goldstein" <peter_m_goldst...@yahoo.com>
Subject RE: JAMES SMTP API sub-project proposal
Date Sat, 23 Nov 2002 06:57:14 GMT

Adam,

> > To achieve this end, I'd like a Mailet API that either uses or
copies in
> > another package the equivalents of the Contextualizable, Composable,
> > Configurable, Initializable, and Disposable interfaces.  I'll leave
the
> > logging question alone for the moment.  I don't think we need any of
the
> > other phases of the Avalon Framework lifecycle (Startable,
> > Reconfigurable, etc.).  So I don't think the Mailet API should be a
full
> > Avalon Framework container.
> 
> Avoiding using Avalon Framework in the Mailet API is a good plan, I
feel.
> The
> API already has equivalents to most of the lifecycle interfaces you
list
> above:

Well, not really.  That's one of the reasons everyone want to revamp the
API.  First off, there is the logging issue.  Just search the archives
for the relevant discussions.
 
> * Mailet.init() and destroy() give you Initializable and Disposable.

True.  Though the contracts for these aren't quite as strict as their
Avalon equivalents.  Especially since init() isn't actually in the
Mailet API.  But these details can be addressed when the API is being
hammered out.

> * MailContext.getAttribute() gives you Contextualizable (as do the
other
> get
> methods on MailContext).

Here's where we'd start to disagree.  See some of the discussion on
Avalon-dev about what precisely is involved in defining a context.  Just
having a context that's a glorified hash map doesn't buy us all that
much.  This is one area I'd like to see addressed by any API/framework
we throw together.

> * Composable can be done with a simple lookup method on MailetContext:
>     Object getService( String roleName );
>   or, perhaps better:
>     Object getService( Class serviceInterface );

This I don't like.  The component lookup should be a part of the Mailet
interface, and separate from the context.  For basically the same
reasons the two are separate in the Avalon interfaces.  They are
conceptually different.
 
> * Configurable could be done using MailetConfig's init parameter
methods.
> Some way of getting at structured config would be better.  It doesn't
> necessarily have to be done via MailetConfig.  A good approach might
be to
> configure the mailets (and maybe the matchers, too) using a
> reflection/javabean based scheme similar to the way Ant configures its
> tasks.

I don't think MailetConfig is anywhere near good enough.  We need
something that is basically identical to the Avalon Configuration
interface - something that allows us to pass in structured configuration
data and supports defaulting and type validation.  Whether the
underlying impl (or even the interface class) is the same really isn't
the relevant point.  The functionality just has to be there.

> Just out of interest, how much scope is there in v3 for changing the
> Mailet
> API, and the way james is partitioned into components?

For the API there is tremendous scope for revamp.  One of the stated
goals for v3 is a new version of the Mailet API.  Input is welcomed.  :)

As far as repartitioning James component-wise, I haven't heard much
discussion of this aside from my comments about RemoteDelivery.  I'm
sure we'd be open to discuss, although I don't think anyone wants to
rewrite everything from scratch.  So the reaction to a repartitioning
request would likely depend on the stated goals as well as the amount of
effort involved.

--Peter




--
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