Re: Proposal: Mail Handling, feedback requested
On 3/24/14, 8:06 PM, Stas Malyshev wrote:
> Gary Mort wrote:
>> My goal is that the creation and sending of basic e-mail should be a
>> simple operation. It should be possible for a developer to simply call
>> the mail() function and not be concerned about possible e-mail handling
>> configurations.
>
> I'm not sure - so how you actually configure the email server in your
> model and what advantage it gives over mail()? Is it just the framework
> for mail() to call? Then it probably should just have one send() method
> and not contain any business logic - that should be either in mail() or
> in specific handlers. I actually like the idea of such class for mail()
> alike to what we did for sessions, but the API should be refined so that
> it matches what people do with emails, and error reporting capabilities
> should be added (e.g. for some applications what email server answered
> is actually important).
Right, the real complication is actually at the PHP configuration level.
At the userspace level it is hard to know how a particular PHP
installation has been configured in terms of what happens when you call
mail(). That is partially by design. Not the information hiding part,
but the separation between the configuration and the mail function
itself and the relative dumbness of that mail() function.
The way I intended, and the way I hoped, people would configure their
PHP and underlying mail setups when I initially wrote the mail()
function (nearly 20 years ago now) was for sendmail (or equivalent) to
run in queue-only mode with a periodic queue run. This has multiple
advantages:
1. Sending an email is virtually instantaneous as far as PHP is
concerned since the email is just written to the local queue (which
could be on the same or a different host on the local network)
2. A high percentage of people have their emails hosted by a small
number of large companies. gmail, hotmail, yahoo mail, etc. So by
using a queue and batch process mode your mail transfer agent will
make a single connection to gmail and send every message destined
for gmail in a single connection even if those messages originated
from many different scripts on your end.
3. Mail transfer agents are incredibly complex. Trying to do any of
this in PHP to any acceptable level of completeness would have been
way too much of a timesink.
I know some frameworks have tried to tackle #3 there because they can't
rely on a sane local mail configuration. I read your suggestions through
twice and honestly I can't quite figure out what you are trying to
solve. Is it #3? It didn't quite seem like it. You still want to let the
system admin define the actual underlying mail stream mechanism, I
think, since #1 and #2 are essential for performance and efficiency. So
it is just a really complicated version of the mail() function, right?
-Rasmus
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc
Thread (10 messages)