On Fri, Aug 21, 2009 at 12:34 PM, Andi Albrecht<[email protected]> 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. > > The ticket currently needs a design decision, so my question is what > the actual concerns to change this are.
I think the original concern was the time required to triage the ticket :-) The original report is fairly light on detail, so I suspect Jacob punted the proposal to DDN in a fit of rapid triage. However, your proposal gives us a bit more detail to work with. On the whole, I have to say I like what I see. This is the sort of thing I'd like to see more of in Django - less specific feature enhancements baked into the core, and more opening of interfaces that let people plug their own capabilities in where they need to. > I would propose the following changes. It's a very simplistic approach > that tries to keep the current API as much as possible: To qualify this - "as much as possible" must include "100% backwards compatible with 0 code changes with all public advertised interfaces". > Add a new setting EMAIL_BACKEND. A string that can be resolved to a > class. Default should be the current SMTP implementation. No problem with this, and follows the precedent set by other backends (such as the cache backend) > 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. I'll need to look into this in more detail. I'm hesitant to lock down APIs like this too much - the more rigid you make an interface, the harder it becomes to use it in interesting way. I'm sure that some insights will emerge as a result of writing the code. > 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. Breaking _any_ third party code is a non-starter. We can deprecate the old name and provide an alias from the old name to the new name, but historical usage must continue without modification. > The test utils could be refactored to use a TestMailBackend instead of > monkey-patching the mail module, but this would be a fairly invisible > change as it would just change the way how the test utils provide the > mailbox attribute in the mail module for unittests. This is an interesting suggestion all by itself. It also dovetails nicely with #8638. That ticket was on the list for v1.1, and originally proposed including a 'test email server'. Ultimately, it was decided not to include an email server, but to document the ways you could use existing mail servers. A 'test email backend' (as well as a dummy no-mail-at-all backend, and a log-to-console/log-to-file backend) is a different way to target the underlying problem posed by #8638. > A nice addition to Django would be to include parts of django-mailer > to provide a backend for asynchronous mail delivery. That could be the > models and command line script to deliver mails. While thinking about > this, django-mailer has a nice option for setting priorities to mails. > IMO Django's API for sending mails should be as simple as possible > (like it is today), but a priority option would be a nice addition > even if the SMTP backend (as the default) wouldn't respect this option > when sending mails. I'm aware of the existence of django-mailer, but I haven't looked into it in detail. At least for the first cut, I'd be more comfortable seeing django-mailer-esque capabilities living as a community project. Then, maybe in the v1.3 timeframe, we can look at adding it as a 'batteries included' backend. That said - if a prototype django-mailer backend were to be developed as part of this development effort, it would go a long way to proving that the backend API you are proposing is sufficiently flexible. The code doesn't need to be trunk-ready, but if you can prove that the needs of a complex email backend can be met with your proposed interface, it goes a long way to proving that your interface is rich enough. > Adding a App Engine backend is not covered here. I think it's up to > third-party code to add support for sending mails on App Engine. > However, such a backend would be pretty easy to implement. This is exactly the right approach. Again, it would be good to develop a prototype backend as a proof of concept of the interface, but that implementation doesn't need to be complete or trunk-ready. > It would be nice to get some feedback on this suggestions and in a > first step to find a design decision about #10355. Even if the > decision is to not change anything for good reasons :) On the whole, I think you're on the right track here. I like the idea, and your design proposal needs some minor tweaking and finesse, but on the whole makes sense. It's certainly worth putting this ticket on the v1.2 feature list for formal consideration. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
