Talk:Requests for comment/UserMailer refactor

April 9th update
This RfC is due to be discussed briefly on April 9th; join us! Sharihareswara (WMF) (talk) 02:30, 8 April 2014 (UTC)


 * Rough consensus is that we should refactor the interface to be cleaner, and probably use SwiftMailer as the new backend. Work on that is apparently ongoing. Expecting to decline this version of the rfc. --brion (talk) 22:08, 9 April 2014 (UTC)
 * Thanks, Brion. User:Owyn, please take a look.
 * Full log of discussion:


 * 22:01:20 #topic UserMailer refactor
 * 22:01:25 #link https://www.mediawiki.org/wiki/Requests_for_comment/UserMailer_refactor by Owen Davis
 * 22:01:35 #info Owen Davis last updated this in late 2013 and hasn't gotten any feedback.
 * 22:01:35 #info Any objection to moving forward?
 * 22:01:51 my main question about the usermailer refactor is whether the echo stuff duplicates/changes the email landscape
 * 22:01:57 (it's such a short RfC, either it's simple or the RfC is too short)
 * 22:02:01 #info my main question about the usermailer refactor is whether the echo stuff duplicates/changes the email landscape
 * 22:02:12 I think it's a bad idea to pass the desired mailer class via the send method.
 * 22:02:20 #info I think it's a bad idea to pass the desired mailer class via the send method.
 * 22:02:28 abstracting the mailer is a great idea, however.
 * 22:02:41  I don't like the growing number of parameters to the static function, it's scary enough already
 * 22:02:44 * awight reads http://wiki.debian.org/MeetBot.
 * 22:02:46  use OOP?
 * 22:03:11 (these seem like things we ought to mention to Owen on the talkpage; I encourage anyone talking now to expand on their thoughts at https://www.mediawiki.org/wiki/Talk:Requests_for_comment/UserMailer_refactor )
 * 22:03:30 agreed
 * 22:03:31 (if they have any expansion on their thoughts)
 * 22:03:36 personally, i find it really odd to even consider a mailer refactor before looking at the underlying mail system (such as Swift_Mailer mentioned in see also)
 * 22:03:41  and where's their code?
 * 22:04:05 good question
 * 22:04:05 yeah, it’s a bit light
 * 22:04:36 parent5446: the end of http://bots.wmflabs.org/~wm-bot/logs/%23wikimedia-office/20140409.txt for the chat till now :)
 * 22:04:36 now it seems the point of the rfc is ‘make it easier to merge the wikia changes’
 * 22:04:45 sumanah: thanks
 * 22:04:51 if that’s mostly ‘we have an extra class and adding these params makes it trivial to plug in’ then that’s probably spiffy
 * 22:04:59  I think this RFC should be declined
 * 22:05:05 i agree
 * 22:05:24 needs moar code
 * 22:05:34  a solution would be a class with eg function addAttachment, not a huge parameter list
 * 22:05:48 and those solutions already exist, we should just be chosing one
 * 22:06:00 Keep in mind we have a GSoC project working on using SwiftMailer in core
 * 22:06:13 That would fulfill most of the goals of this RFC
 * 22:06:32 #info seems to be some agreement that using SwiftMailer as backend would resolve this better
 * 22:06:39 so it sounds like someone should summarise this for the RfC talk page, or possibly we should just decline this
 * 22:07:15 i’ll add a quick note
 * 22:07:29 #action brion to summarise this discussion on RfC talk page (re user mailer)
 * Sharihareswara (WMF) (talk) 11:30, 10 April 2014 (UTC)

Mailer componentization
I think the extra parameters to send are a bad idea because they actually increase code coupling, and break encapsulation. On the other hand, the prose description of changes sounds like a much better idea. Yes, we should abstract the mailer so that it is swappable with any compatible implementation. Adamw (talk) 22:05, 9 April 2014 (UTC)
 * Looks like this RFC is going to be superseded by an integration of Swift Mailer, which would accomplish your suggestion. Owyn (talk) 21:11, 17 April 2014 (UTC)