On 06/08/2007, at 9:40 AM, Fabien Schwob wrote: > How is it possible to help ? I'm about to write somethink like > django-mailer for a website I maintain, so I think it's better to > contribute to django-mailer. > > Does you already have an idea of the architecture of this future app ?
First of all look at the notes on http://code.google.com/p/django- mailer/ Here are some more thoughts below which I'll add to the project wiki soon: I'm a big believe in a step-by-step approach so I was going to postpone support for deferred sending (e.g. send this email out at 3am tomorrow morning), recurring email (e.g. password change reminders) and for box-carring (i.e. putting multiple notifications in a single email) until later releases -- especially as a believe these can be cleanly layered on top of the basic functionality. With these features initially removed, the models I have in mind is fairly straight forward. The main model will just be a queue of fully resolved messages to send as soon as possible. By "fully resolved" I mean that any template processing will take place before the message gets added to this model. So, in other words, the model will contain the literal to, from, subject and message body as well as a datetime of when the message was added to the queue. I'm also thinking of a three-way priority -- high, medium, low (see below for what this means). I'm thinking of implementing the "don't send" list at this level, so even if you put an email to someone in this low-level queue, it won't get sent if the email address is on the don't send list. From experience, it's worth implementing this kind of opt-out support right from the beginning, so the initial version will have this second model, a simple list of email address not to send to, perhaps along with a datetime of when the opt-out was added. The third model for this initial version is a log. Regardless of whether a send succeeds or not, it is logged in this model. A separate process can be responsible for retries, rolling to file- based logs, archiving or whatever. I am inclined to include everything in this model that is included in the first model (including the message body). In additional there would be a datetime of when the send was attempted, a status code and some free-text field to capture an exception. I believe that all other features including retries, deferral and box- carring can be implemented on top of this layer with little or no modification. One thing I haven't thought enough about is how this bottom layer would handle (or integrate with handling of) mail delivery failures that come back as email (rather than exceptions thrown by SMTP subsystem). Things to consider are how to correlate the mail delivery failure email and exactly what to correlate it with (the entry in the log model?) One thing the above models do not consider is the possibility of multiple queues. I'm calling YAGNI on that at the moment. So there would need to be one process that, when invoked would simply go through the queue, attempting to send each email (after checking the don't send list) and logging the result. My thoughts about priorities are that the "sender process" should first go through any "high" priority sorted by age (how long they'd been in the queue), then any "medium" sorted by age, then any "low" similarly sorted by age. Finally there should be a view and template for showing basic status of the django-mailer system. Obviously later releases will add functionality on top, mostly concerned with how to get things in the queue and when to put them there. So my initial plan is to implement what I've described above. But there needs to still be, for the system to be usable for more than just one-off emails to individuals, a basic mechanism for adding bulk mail to the queue. The simplest case is one where an identical (i.e. no templating) text email is sent to all users. Adding templating support is only a small step from that, assuming that the template just receives a user object in the context. Then what is needed is a query set of what users to mail to. So bulk email is achieved by running a choice of query set + template and adding each result to the message queue in the layer described above. So after a first pass of the lowest layer (described above) is done, I plan to add this kind of bulk email support per the previous paragraph. Thoughts? (again, I'm happy to take this to a dedicated list if people prefer) James --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
