Re: Proposal: Mail Handling, feedback requested

hi Gary, On Tue, Mar 25, 2014 at 2:59 AM, Gary Mort <garyamort@gmail.com> wrote: > Current e-mail handling in PHP is dreadful. Almost every framework > implements it's own email handling class in order to make sending e-mail > reliable, easy to configure, and to implement multiple mail schemes. > > > This means for developers working on multiple frameworks, they can't just > call mail($recipient, $subject, $message) - they have to perform convoluted > checking to find out what framework they are using, and then use the > appropriate api. > > That was understandable in PHP v4 and in v5 - 5.2. > > Today though it is a waste of time, PHP internally has implemented a smart, > extensible system for generalizing access to system oriented structures. > Handlers/Wrappers. > > By subclassing the appropriate handler class, a PHP application can > implement specific functionality to handle specific elements of Session and > Stream processing, without having to implement every one of them and without > requiring specialized PHP classes to be used directly. > > http://www.php.net/manual/en/function.session-set-save-handler.php��lC2���~ > �|d > http://www.php.net/manual/en/function.stream-wrapper-register.phpa > ��8a!'gQW� > http://www.php.net/manual/en/class.sessionhandler.php > http://www.php.net/manual/en/class.streamwrapper.php > > > My proposal[which I am willing to work on coding] is to replace the current > mail() function with one that will support handlers. > > Note: This is only to handle HALF of the issues that we deal with when > sending e-mail: sending the actual message. It does not attempt to address > creating/formatting e-mail messages except in a very general since. My > proposed class would be: I do like the idea to simplify or making developers life easier while working with emails. However your last note summarizes pretty well the problem. No matter what we do or provide, I am somehow convinced that applications, frameworks or components developers will wrap something around it to match more closely their needs or flows, like swift mailer for Symfony. That's why I am not totally sure it is a good idea to implement something high level when users already rely on php compoenents (userland) heavily for this job. By the way, a similar discussion happens for imap, both cases are very similar, there is no performance gains to do it in the core and that's why I tend to think to leave things as is (well, killing ext/imap for security reasons f.e. :) instead of trying to create something that won't match users need fully anyway. If there were an immediate gain for our users (performance or easiness), I would be all for it, but that's not the case, to my understanding. Cheers, Pierre