james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: MailRepository
Date Thu, 14 Nov 2002 02:51:46 GMT
Aaron,

As I just said in James-User (but let's move the discussion over to here):

Seems to me that you don't need what you've done.  A mailet and the internal
spool would provide sufficient decoupling to generate SMS to an EJB backend.

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

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

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

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.

> 2) Expose the ability to define mail repositories through config.xml
>    *and also to process the mail in them*.  At present there is the
>    ToRepository mailet to put mail in a repository.  The trouble is
>    that nothing happens to the mail once it is written to a repository.

> I am thinking that this could be extended to include the ability to
> define a processor that is associated with a named repository.

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.

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.

We're very close.  I'm hoping that Peter (v2.1 Release Manager) can post a
Release Plan Status, so we can talk about who is doing what to help push
this to completion and get into some really fun new stuff.

	--- Noel


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