search

fuelphp-storage / email

FuelPHP Framework - Email library
1 stars 1 forks source link

Use third-party? #9

Open sagikazarmark opened 10 years ago

sagikazarmark commented 10 years ago

IMO this question popped up somewhere (maybe the roadmap?) but has not been answered. Currently 40% of the library is ready, so if this question is still open, it should be answered now.

I am currently looking at the following implementations, but I am not fully happy though: https://github.com/PHPMailer/PHPMailer https://github.com/swiftmailer/swiftmailer

These two are the most powerful ones I've found. It seems that they have the same features.

There is also a third party email sender with implementation for third-party email solutions, like Mandrill, Mailgun: https://github.com/henrikbjorn/Stampie

However, this is probably not the best solution as it does not use the official API SDKs.

I know @WanWizard you don't like the idea of third-party packages, but probably an email implementation is something that should not be reinvented. Both package has a great background, support is probably not a problem. However at this point I can't say which way is better: create our own or use an existing.

WanWizard commented 9 years ago

As said before, I don't have a problem with third party packages perse. But they have to meet a list of requirements, to make sure there is no impact to our product, the framework. And there can be impact in terms of reliability (you don't want the framework to have an issue because the external package has developed one), or performance (every feature has an impact).

In this specific case, I am perfectly happy with the functionality of the current Email package (v1), and I think that in 90% of the use cases it will work fine. It's lean, fast, and it gets the job done. If you want more, nobody is stopping you from including another package, it's the advantage you will have with v2 and composer.

But that should not force me to do the same, which is what would happen if we would drop the current package. Both PHPMailer and Swiftmailer are huge, complex, and come with tons of overhead.

You have to distinguish the requirements you may have as an application developer from the requirements needed to develop the framework.