Version 1 by Gavin
on Jun 16, 2006 17:09.

compared with
Current by Gavin
on Jun 16, 2006 17:09.

(show comment)
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (16)

View Page History
h1. Zend_Mail, Zend_Mime, Zend_Mail_Transport Goals
* API remains clean and simple
* minimal changes to API exposed to developers
* easy to use
* Zend_Mail_Mime can be used independently
* Zend_Mail_Transport_* can be used independently
<h1>Zend_Mail, Zend_Mime, Zend_Mail_Transport Goals</h1>
<ul>
<li>API remains clean and simple</li>
<li>minimal changes to API exposed to developers</li>
<li>easy to use</li>
<li>Zend_Mail_Mime can be used independently</li>
<li>Zend_Mail_Transport_* can be used independently</li>
* Zend_Mail <li>Zend_Mail does not require the developer to use or understand the API for the two classes above</li>
</ul>

Like to Have:
* common interface / API for "messaging", including support for adding transport mechanisms other than SMTP, and mail(), such as developer provided transports (e.g. web service API interfacing to an email application server, IM, SMS)

h1. Message Assembly
<p>Like to Have:</p>
<ul>
<li>common interface / API for &quot;messaging&quot;, including support for adding transport mechanisms other than SMTP, and mail(), such as developer provided transports (e.g. web service API interfacing to an email application server, IM, SMS)</li>
</ul>

Problem: Raw message assembly for SMTP and mail() differ, and solutions proposed require binding the classes more tightly, or moving control of the final assembly to the transport.

Problem: Other transports will likely place greater burden on Zend_Mail, as Zend_Mail would need to be altered to provide sufficiently detailed, structured information to assemble the raw message format native to that transport's protocol.
<h1>Message Assembly</h1>

h2. Rationale for Placing Final Assembly of Protocol-Dependent Messages into the Transport
The final, raw, assembled message data structure depends on the transport. Even 8bit encodings become quite difficult for us to create outside of the ZF transport clases, as mentioned previously, unless we bind the transport "closer" to Zend_Mail. For transports other than SMTP and mail(), the structure of the final message varies significantly from that needed by the SMTP transport. However, the data supplied by a consumer of Zend_Mail might be identical in many cases. I'm not sure how such complexity could be modularized and encapsulated, if all such raw, protocol-dependent message "assembly" logic resides within a single class, Zend_Mail.
<p>Problem: Raw message assembly for SMTP and mail() differ, and solutions proposed require binding the classes more tightly, or moving control of the final assembly to the transport.</p>

However, I can imagine Zend_Mail assembling the data into a common, internal format suitable for use by transports that contain the raw, transport-dependent message format construction logic. I can even imagine a developer creating messages using Zend_Mail and then sending the same message over multiple transports, or changing one part of a message, and then sending variations of the message (i.e. standard, commonplace "mail merge") over different transports, based on user preferences settings (i.e. users of their web application).
<p>Problem: Other transports will likely place greater burden on Zend_Mail, as Zend_Mail would need to be altered to provide sufficiently detailed, structured information to assemble the raw message format native to that transport's protocol.</p>

<h2>Rationale for Placing Final Assembly of Protocol-Dependent Messages into the Transport</h2>
<p>The final, raw, assembled message data structure depends on the transport. Even 8bit encodings become quite difficult for us to create outside of the ZF transport clases, as mentioned previously, unless we bind the transport &quot;closer&quot; to Zend_Mail. For transports other than SMTP and mail(), the structure of the final message varies significantly from that needed by the SMTP transport. However, the data supplied by a consumer of Zend_Mail might be identical in many cases. I'm not sure how such complexity could be modularized and encapsulated, if all such raw, protocol-dependent message &quot;assembly&quot; logic resides within a single class, Zend_Mail.</p>

<p>However, I can imagine Zend_Mail assembling the data into a common, internal format suitable for use by transports that contain the raw, transport-dependent message format construction logic. I can even imagine a developer creating messages using Zend_Mail and then sending the same message over multiple transports, or changing one part of a message, and then sending variations of the message (i.e. standard, commonplace &quot;mail merge&quot;) over different transports, based on user preferences settings (i.e. users of their web application).</p>

<p>I'm biased towards allowing for the possibility of adding a robust "mail merge" &quot;mail merge&quot; capability with dynamically selectable transports, and the ability to revise a message and resend over a different transport. I actually have needed this functionality previously.</p>