[ic] email tag - large lists problem
lists at gmnet.net
Tue Feb 9 07:04:03 UTC 2010
On Fri, 2010-02-05 at 20:08 +0000, Lyn St George wrote:
> On Wednesday 03 February 2010 20:41:37 you wrote:
> > Hi Lyn!
> > Lyn St George wrote:
> > > On Wednesday 03 February 2010 18:49:34 Rick Bragg wrote:
> > >> Hi,
> > >>
> > >> Is there a way to use the email tag so that IC does not have to wait
> > >> after sending out all mail before returning a page?
> > ....
> > > To solve this kind of problem in the past I've simply handed the job over
> > > to the system via the at daemon, and a custom tag to do it. This frees IC
> > > to immediately get on with it's main business
> Hi JoJo - good to see that you're still around:)
> > Can you show me the right direction, to find more information about this?
> > I'm involved in a new project, with sending mass emails (from 500 up to
> > perhaps 2000) and THIS is NOT a spam project. It is a project to send a
> > signal for any helps by Police, emergency physician and so on...
> > Such kind of messages is hurry and has an extra reason to inform the
> > reciepient about the current incident.
> > The primary message is transmitted per SMS. After that, such kind of
> > message has to send per email as soon as possible. The arrival
> > (timestamp) of the email, is not my problem.
> > Can you share your custom tag with me?
> > Have a nice day!
> > jojo
> I've written a generic version, called it 'schedule_at.tag' and put it on
> http://kiwi.zolotek.net along with a few words of explanation.
> Basically, it can either have 'at' execute a file immediately (ie, 'now + 1
> minute') or specify a date in the future for execution. The file to be
> executed will do all the heavy lifting in terms of looping through a list of
> email addresses and sending emails out. One neat thing about using 'at' is
> that you can feed things into the environment when the atjob is created, they
> will be stored in the atjob and then exported into the new environment when
> the atjob is run. Obviously a useful feature.
This is all really great, and yet again shows the strength and
flexibility of IC. Same here, it is NOT SPAM, but for city alerts that
people subscribe to. Delivery time is somewhat critical, but deliver
reliability and avoiding the browser from hanging is more important.
Also, these "lists" need to be totally dynamically created, and
One quick question about schedule_at, and child-process vs. a real
mailing list like mailman; Would any of these survive an interruption
caused by a reboot? Probably mailman or sendmail alias?
More information about the interchange-users