james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Doucette <da...@citilink.com>
Subject Re: Remote delivery updates
Date Mon, 11 Jun 2001 18:59:44 GMT
>From david@citilink.com
From: David Doucette <david@citilink.com>
Reply-To: david@citilink.com
X-Sender: david@mail.citilink.com
X-Mailer: ELM [version 2.5 PL2]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> > From david@citilink.com
> > > No docs to speak of.  As it tries messages, if it fails it puts it back
> in
> > > the queue, incrementing a counter and recording the next time it should
> > > attempt (based on the conf file).  So if the server is restarted, it
> will
> > > remember where it was.
> > So the queue exists in memory and on disk?
> 
> Nothing exists in memory.
Ah, I guess I just assumed for reasons of performance everything was read 
from memory.

> > Very cool.  As I think more about this, maybe it should be even more
> > general purpose -- not only handling failure, but also success (or a
> > separate one for each case).  This way actions can be taken as the result
> > of a successful delivery, not just as the result of a failed delivery.
> > Again, I'm new to James, so maybe there is already some sort of
> > mechanism to cause an action to happen upon success?
> 
> Messages for delivery just get consumed (success or failure).  I like the
> idea of another processor for successes, not that most people would use it
> (at least not today).
I agree that most people wouldn't use it.  My motives aren't entirely
altruistic.  *Grins*  However, once the engineering is done for
failures, it should be easy to do the same for successes
(theoretically).  My initial thoughts are that it would allow for:

-  Call-backs/notifications/database updates to keep track of how many
emails each address has been sent
-  The same to make it easy to write a monitor program that shows the
progress of a batch of emails.

I work with clients who send millions of emails/week (not SPAM).  They
would love to have this type of flexibility.  It also makes it much
easier to integrate James with other systems.

David

> Serge Knystautas
> Loki Technologies
> http://www.lokitech.com/
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
> 
> 


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


Mime
View raw message