Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73420
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <5330E319.5060302@gmail.com>
References: <5330E319.5060302@gmail.com>
Date: Tue, 25 Mar 2014 11:21:55 +0100
Message-ID: <CAEZPtU5fZT0REf3cr-CcWQhWovpWi5iO3jMHVgeyKZR5SkLMwg@mail.gmail.com>
To: Gary Mort <garyamort@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Proposal: Mail Handling, feedback requested
From: pierre.php@gmail.com (Pierre Joye)

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