You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I don't think we should provide too many provider out of the box as it will slow our capability to provide new features. Instead we should rely on the community to bring that support. In addition, most providers have an smtp api, so our smtp provider can be used as a fallback.
That said, if we want to extend the feature coverage of our abstraction, this might make sense to have 2-3 commercial alternatives. We should select them based on Quality Of Server, Features and Market Share. This article provides a few insights.
The text was updated successfully, but these errors were encountered:
I'm not sure if it's really necessary to support alternative providers right now, unless one of us do have the specific need.
Alternative providers would be great for our library's notoriety, but before that we should complete the other issues (CC, BCC, Reply-To), create the documentation and write unit and integration tests.
Once we have done that, hopefully someone would ask or contribute to add other providers. Or, we could choose the most trending one :)
I don't think we should provide too many provider out of the box as it will slow our capability to provide new features. Instead we should rely on the community to bring that support. In addition, most providers have an smtp api, so our smtp provider can be used as a fallback.
That said, if we want to extend the feature coverage of our abstraction, this might make sense to have 2-3 commercial alternatives. We should select them based on Quality Of Server, Features and Market Share. This article provides a few insights.
The text was updated successfully, but these errors were encountered: