james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Knauf <akn...@xtra.co.nz>
Subject Re: MailRepository
Date Thu, 14 Nov 2002 05:16:38 GMT

Noel J. Bergman wrote:

> Just have the mailet do this when the service method is called.  If you need
> something else, just clone what RemoteDelivery does, which is basically the
> same as your mailet.  It uses an internal spool when it can't immediately
> deliver.  We could probably refactor RemoteDelivery into a base class for a
> certain category of mailet, and then provide methods for performing the
> remote delivery, e.g., to another SMTP server, to your EJB server, to
> another server.

I seem to recall reading through RemoteDelivery at the time we were 
writing our mail repository access code.  We do esentially do the same 
thing in our mailet - and for the same reasons.

Making RemoteDelivery into a generic base class would give us the 
independence from the JAMES internals that we are after for our 
immediate requirements.  However, the next phase of our app requires 
storage of all forwarded messages for a minimum of several days, 
regardless of transmission success/failure.  A subclass of 
RemoteDelivery would not give that kind of flexibility, I imagine.

>>I think the JAMES mail repository needs to be exposed to mailet authors.
> I agree that repository access needs to be provided, but I do NOT that the
> Repository interface currently present is what ought to be used, either by
> James or by Mailets.  I also agree that whatever the interface to
> repositories, James and Mailets ought to use the same one.

Agreed - the actual interface provided should not be MailRepository 
without modification.  I'm sure you've thought that aspect out far more 
thoroughly than I have.

>>We would like to be able to define an arbitrary mail repository, store
>>incoming mail into it and process that mail asynchronously.
> See above.  It sounds as if you team is going about it all wrong.  Please
> read through the RemoteDelivery mailet.

See above - we did read RemoteDelivery.  ;-)

>>1) Expose the MailRepository interface in the mailet jar file
>>   and provide a standard way to get a reference to to a
>>   particular repository.
> That depends upon what form the mail repository takes.

?????  Why should the 'form the mail repository takes' affect the 
interface or the method used to get a reference?  If I have two 
repositories, one of which stores its mail in a RDBMS while the other 
uses the filesystem, why should I not be able to say

MailRepository rep1 = getRepository("MyDbRepository");
MailRepository rep2 = getRepository("MyFileRepository");

This simply requires that the repositories be configured and named via some
other mechanism, such as a config file.

> However, although I am really kind of itching to get into these issues, we
> have a bit of an agreement to keep a bit of a lid on James v3 discussions
> until after we get release 2.1 out the door.  Danny also has a lot of ideas
> that he wants to post, as do others.

Fair enough.  I won't push the point any further at this stage.  We will 
be wanting to hold off on any JAMES version upgrades until this bit 
settles down, though (unless something falls apart on 2.0a1).

> Right now Spool repositories are uniquely handled by the linear processor,
> and internally by RemoteDelivery.  I generalized what you are describing
> into further decoupling things to use use repository storage in similar
> fashion to tuple-spaces.  I have been thinking about that since looking at
> concurrency, since tuple-spaces and JSR 166 have some similar concurrency
> notions.  This approach would permit some of the more interesting ideas
> people have asked about, such as load balancing.  James could actually run
> on a network of machines, providing for amazing scalability.

Yes, essentially you are correct about the tuple spaces.

The key aspect of my suggestion is the idea that the spool repository 
would no longer be unique.  There could be any number of repositories. 
Some of these could be spool repositories.  A spool repository has an 
associated processor, others do not.  There would always be an incomming 
mail spool repository, associated with the root processor.  The 
RemoteDelivery mailet is then replaced by another spool repository 
associated with a processor containing a RemoteDelivery mailet that 
performs remote deliveries, but does not need to perform any repository 
handling of its own, or thread management.  The semantics around removal 
of a message from a spool repository and locking of a message while 
processing it would need to be defined carefully, but would probably be 
very similar to those used by JMS queues.  In fact, a JMS queue could 
easily be used as a spool repository implementation.  (Ah ha!  Now 
there's an interesting thought - that would make spool repositories 
quite different to other repositories. JMS is a queueing mechanism, not 
a persistent storage mechanism.)

> My view is that this is the time to consider any radical restructurings.  We
> can maintain a James v2 architecture release with bug fixes, but allow James
> v3 to build on new ideas that have come up based upon experience with James
> v3.  But first we have to get v2.1 out the door.



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

View raw message