On Fri, Aug 21, 2009 at 11:53 AM, Zachary Voase<[email protected]> wrote: > > Hi Andi, > > On 21 Aug 2009, at 05:34, Andi Albrecht wrote: > >> Hi, >> >> I'm interested in working on #10355 "Add support for email backends." >> >> IMHO it's an good idea to make the email backend configurable. There >> are at least two use cases I can think of. The first is to send email >> with other services than SMTP, like App Engine as noted in the >> ticket's description. The second is to deliver email asynchronously, >> like the django-mailer application does already. > > I wholeheartedly agree. > >> The ticket currently needs a design decision, so my question is what >> the actual concerns to change this are. >> >> I would propose the following changes. It's a very simplistic approach >> that tries to keep the current API as much as possible: >> >> Add a new setting EMAIL_BACKEND. A string that can be resolved to a >> class. Default should be the current SMTP implementation. >> >> Provide a base class for mail backends. A mail backend must provide >> the method send_messages(email_messages) and must return the number of >> messages sent to provide backward compatibility. The constructor of a >> mail backend should take at least the keyword argument fail_silently >> (default: False). What I'm a bit unsure about are additional >> constructor arguments. Currently the SMTP backend allows in addition >> host, port, username, password and use_tls. Those are very >> SMTP-specific, but only username and password are used by the >> mail.send_mail* APIs. It would be an agreement to allow username and >> password in addition to fail_silently to not break the send_mail* API. >> The SMTP backend could accept host, port and use_tls as extra keywords >> again to provide backward compatibility for code that directly uses >> SMTPConnection (within Django SMTPConnection is not used outside >> django.core.mail). I would suggest to rename SMTPConnection to >> SMTPBackend, but only if this would break too much third-party code as >> SMTPConnection is mentioned in the docs. > > This I disagree with slightly. My main concern is the single-backend > architecture; many websites will probably want to use more than one > method for sending e-mail. In addition, if mail backends only need to > implement one method, why not just have EMAIL_BACKEND refer to a > callable instead? > > In terms of the SMTP-specific settings (host, port, username, password > and use_tls), I personally feel that those parameters should be in the > settings module and not in the code. Although at the moment, > django.core.mail will use certain settings if said parameters are left > out. > > I think a slightly better architecture would be this: > > * Make full use of the existing Django signals framework to send e- > mail. Have callables which implement 'send_messages()' connect to a > 'sendmail' signal through the use of a simple decorator or connector. > These callables will connect with the 'sender' keyword argument, which > will be a string which uniquely identifies that backend; so AppEngine > might be 'app_engine', SMTP 'smtp', and so on.
I have some concerns with this. Letting a backend connect to a sender that determines the backend to use implies that someone who wants to use the mail API already needs to know which backends are available and has to decide which backend he wants to use. I think it's up to the administrator to choose which backend should be used for sending mails. The send_mail functions should be agnostic of this setting. OTOH signals could be a nice addition and could be used for example to log failed messages or to modify messages before sending. But I wouldn't use them to actually send the message. > > * To send a message, just send on the 'sendmail' signal, with a > 'sender' equal to whatever backend you want to use for that particular > message or batch of messages. Failing silently can be done with the > signals framework, using 'send_robust()' to catch errors and then > deciding whether or not to raise them later. Of course, nice wrappers > would be provided over all of this, so that the code which sends mail > does not need to know the signals API. > > * E-mail backends can, by default, configure themselves from the > project settings. Using signals means that it’s also quite easy to > dynamically create a backend, connect it to the dispatcher, send some > signals, and then disconnect it. > > What do you think about this? I might work on a simple proof-of- > concept reusable application. > > Regards, > Zack > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
