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. * 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 -~----------~----~----~----~------~----~------~--~---
