RE: [Dnfbb-developers] Mail

[Si C. <sim...@te...>]

> -----Original Message-----
> From the options presented below I have to say that I prefer the 
> second option as I think this would give the most power and 
> flexibility even though it might need a little more work to implement.

I agree, however if anybody has more ideas on ways of doing this I would
welcome hearing them.

 
> As indicated in the original post there could be a large amount of 
> mail being generated with mailing lists etc... and if you are to send 
> it directly this could generate a lot of activity on the server end.  
> The draw back to not sending it straight away would have to be weighed 
> up against the volume of email being sent at that time.  For the odd 
> email this is fine but for large mailing lists it could be better to 
> delay it.  Being able to schedule it would provide the forum admin 
> more power and control over how the mail is sent.  The only problem is 
> that you wouldn't want to be waiting too long for a simple 
> registration email to be sent to you before you could join the forum.

Agreed, some sort of internal priority scheduling would need to happen.  

>  
> By using a scheduled task, which interacts directly with the database, 
> you can achieve a lot more control over the way in which the mail is 
> delivered.  By implementing this type of scheme there would be nothing 
> to stop you running a number of different schedules which controlled 
> the way in which the mail was transmitted.  For example, there could 
> be a schedule which handled all internal mail (user to user within the
> database) which ran at a different rate to the mailing lists which 
> runs at a different rate to the external mail schedule.

One thing to keep in mind here is a web hosts compliance in running multiple
scheduled tasks, some will be reluctant, where as others will be eager to
please.  

>  I do like the idea of the task hooking into the database directly.

Agreed, I wrote FBMail specifically for sending mail directly from a
firebird database, with dnfBB in mind.  It gives us, imo, a lot more
flexibility and should speed up the presentation layer as the mail will be
generated in stored procs on the database server and sit waiting until its
sent.  Also, if there is a problem sending from the presentation layer it is
virtually impossible to reschedule the mail.

Another thing to keep in mind is incoming mail, and how this will be
processed.

Rgds

Si