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
> http://www.php.net/manual/en/function.stream-wrapper-register.php
> 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
Thread (10 messages)