On Fri, Aug 21, 2009 at 7:23 AM, Russell Keith-Magee<[email protected]> wrote: > > 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".
OK, that's clear :) I fully agree. > >> 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 dummy backend/log backend sounds good. I'll add them. Is it time to make the mail module a package? Preserving the current namespace, of course... > >> 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 -~----------~----~----~----~------~----~------~--~---
