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: MailRepository
Date Thu, 14 Nov 2002 03:47:21 GMT

Noel and 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 agree with Noel - I don't understand why the special spool is
necessary.  Use of a custom mailet to generate your EJB calls seems more
than sufficient.

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

I agree with all of this.  I'll take it one step further.  There needs
to be a way for mailets to access all components provided by the server.
This should be supported by the mailet API.  If a required component is
not available the mailet needs to be able to throw an exception on
startup to notify the mailet container.

As far as the repository interfaces go, they all need a lot of work.  In
James 3.0 I expect we will be making substantial revisions to these
APIs.  I know Noel and Serge have a lot to say about the mail
repositories (properties/attributes) and I have more than a few thoughts
on the user repositories.  I have no idea what anyone else has to say,
but I'd be pretty naïve if I didn't believe that Danny and others will
champion certain modifications.  I also think that support for IMAP and
NNTP in the standard repositories will force certain restrictions on
these interfaces.  So calling these interfaces in flux would be an
understatement. :)

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

You should be able to do this, but I concur with Noel.  Why would you
want to do this for your app?

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

Will do.  We are close.  Watch for it soon.

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