Conversation
|
Please no, no more breaking changes for e-mails. It's too much money spent on this from everyone trying to keep up. |
|
I understand what you mean, believe it or not, the last implementation, with all the respect, brings a lot of types and introduces a lot of complexity. I'm still suffering in Orchard Core Contrib (OCC), for instance, because I'm managing 4 email modules @Piedone, please think from both the developers & customers' perspectives |
|
FYI, this is not because I'm one of the maintainers of OCC, it's also feedback from other devs that doesn't show up on public. I still remember when @sebastienros (if I'm not wrong) started this module; it was straightforward, after that the new changes brought some flexibility but introduced complexity. So, let's hear the folks' feedback |
|
Please present what the problems you see are exactly, and how you propose to solve them in this PR. |
|
This pull request has merge conflicts. Please resolve those before requesting a review. |
|
Who added complexity to my straightforward implementation ;) We should start this by a design discussion, looking at the PR I don't see how this is "simpler", maybe the word is the wrong one. |
This is simpler than the current one :) I tried to remove unnecessary types as much as I could. Also, I have a keyed service implementation in my local I never mind starting a design discussion about this, but we need to do it before |
3 participants
After the last updates on
OC.Email,OC.Email.Smtp, andOC.Email.Azuremodules, the email APIs become extensible but introduce a lot of complexities and extra types that can be reduced for simplicityFor those who maintain more than 2 email providers, such as Orchard Core Contrib (OCC), this will cause pain. TBH, the email APIs at the beginning were straightforward