On 3/9/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-03-08 at 04:09 -0800, Simon G. wrote: > > Good Evening Djuggernauts, > > > > I've spent some time looking over the email related tickets in Trac, > > and think I've got them sorted out a bit. I'm hoping to spur some > > discussion on some of these, so here's a brief recap. > > Nice work, again, Simon.
Ditto. This sort of filtering isn't easy - good stuff. > > We currently have requests to: > > > > #1541 - Add Multipart Message capability to mail > > This ticket's first birthday is creeping up. There's a patch here > > that adds a safe method for sending multipart messages. Jacob has said > > this is great, but it needs docs. HOWEVER, Gary Wilson's pointed out > > that we're getting a rather ugly data tuple going on, and created 3366 > > The main reason I suspect it hasn't been resolved one way or the other > is in Russell's comment #23 in early March: it's become a nest of > competing implementations, which is never an easy thing to untangle. > Having discussion in bugs is good, but it sometimes ends up like that. There have been a few attempts to get a mailing list discussion started in the past few months, but nobody has taken a serious swing at the problem. > I haven't read the patches closely, but my immediate concern is whether > we are duplicating too much of Python's existing mail framework and just > wrapping it. That would be bad design. I have no opinion on this yet. Looking over the patches again, I share this concern. The original intent of send_mail was to provide a simple "just send a message" API, mostly for the purposes of emailing the site admin error messages. James' comment about mailing perty HTML stack traces is a good one, but otherwise the python email libs provide a much richer API, with exposure of the full set of possible email options. I'm +1 on exposing some extra options that fit with existing options (like SSL sending and BCC's - 2897,3366), and the problems with charset encoding should probably be fixed, too (2007,3472). Personally, I'm not a big fan of HTML email, but I seem to be in the minority on this one; as long as the interface (1) remains simple, and (2) enforces best practice (such as requiring text as well has HTML), I could live with the change. Some cleanup of option passing might be called for as well (3366, but I prefer Malcolms dict-based approach). However, over all these changes, we need to be careful that we don't just replicate the python mail APIs. 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 -~----------~----~----~----~------~----~------~--~---
