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. > > 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. 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. > #3366 - objectify send_mass_mail parameters > This aims to clean up the send_mass_mail arguments by plugging them > into an object. This looks fairly sensible, and has a patch, but has > some backwards incompat. issues. This needs a design decision - and if > it's "yes", then the other tickets will probably need to be rewritten > to take this into account. If things like #1541 are deemed useful, this is a probably a good idea. Particularly because so many of the arguments are optional. I'm not sure why Gary wants to use an object, rather than a dictionary, since dictionaries are often easier to construct in client code if you're doing it all in once place. There's also nothing really object-y about the data: it's just a bag of name/value pairs. Using an object makes using the values easier (foo.bar versus foo["bar"]), but creating them is more verbose. The principle seems sound; we should decide about this pre-1.0. > > #2007 - Enable email sending in a non-default encoding. > A pure feature request to add a new setting that could override the > charset that emails are sent in. No patch, and I'm not sure how useful > this would really be. Let me know if I'm wrong here. Not really sure of the benefits of this. The main motivation given in the comments is to avoid the base-64 encoding, which is #3472 (you missed that one). I think we should fix #3472 in some way (I'm with Jacob on not quite understanding the patch fully, yet, but it looks like the right idea) and then if people want ultimate customisation they have the Python email support anyway. Django's email stuff is just for convenience in common cases. > > #2897 - Support TLS > This has a simple patch, and could add some nice functionality. > Adrian wontfixed it 6 months ago, but it's been reopened and a couple > of people are arguing that it's a good feature. [yes/no]? Mostly because of Google (as mentioned in one of the comments), I would vote to fix this. > #3307 - Add BCC to mail framework. > I've renamed this ticket from what it used to be. This originally had > two issues - one which overlapped with #1541, and the other this BCC > request. There's a patch here with adds a parameter to send_mass_mail > to suppress the recipient list (i.e. by BCC'ing them), but Gary > Wilson's argued that it's more logical to have two parameters: > recipient_list & bcc_list. So - this just needs a design decision on > what path to take (if any). I'd argue again that complex stuff can already be done with the Python framework. Why are we wrapping it? So I guess I'm -1 on this at the moment (I'm willing to wrong about why we are wrapping certain things and not others). > #3605 - Simple patch to give content-type definition for sending html > mails. > This one looks like a quick design decision. Anything that encourages people to send pure HTML email without including a text copy deserves to be wontfix-ed. :-) It has the same problem as you pointed out earlier: yet another parameter. I'm probably +0 on this one (not enthused, but it wouldn't hurt too much). We need an easy way to send 404 and 500 emails and some integration with the site's settings (the latter being the motivation for wrapping so much stuff, I guess). Most other stuff seems like gravy. For my money, #3472 and #2897 look like important ones that need fixing soon. #3366 looks like a good idea for period between 0.96 and 1.0 because of the backwards-compat changes. For the rest, I'm willing to defer to others, since I don't use them and so am probably being too negative. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
