On Jun 20, 2010, at 9:03, Will Scheidegger wrote:
> > Thanks Jan and Philipp for the feedback. I was not aware of the fact that > including scripts in the head section would be treated differently by clients > / spam filters than simply linking to scripts. Either way, most clients will (rightfully) ignore the javascript in email bodies; especially webmail clients. What kind of JS did you want to include in a mail ? > > On 18.06.2010, at 14:46, Jan Haderka wrote: > >>> - a SerialMailCommand extending MailCommand supporting the production and >>> delivery of serial mails >>> [...] >> >> what is "serial" mail whose content goes through series of transformations >> or mail that is personalized for each client differently and hence has to be >> re-processed or both? Not sure from the description. > > Same thing. What I meant: The mail body should be prepared first (e.g. the > HTML content fetched from the provided url, images attached etc.) and then > stored in the mail. Then when sending the mail to each recipient, there > should be the option to personalize the mail with parameters stored with the > recipient. Afaik, you can already do something similar with FreemarkerEmail ? At least at some point, it used to be able to "post-process" a page containing place holders. Either way, this would need to be simplified/clarified. > >> This again would be doable, but having 10K list of subscribers, generating >> such mail might be bit too much load for the server (which is why we tend to >> integrate external specialized solutions for this kind of processing like >> campaing monitor). > > Agreed for enterprises with huge recipient lists - although if you properly > split the delivery in small batches the load is not too bad, it will just > take its time. Then again for the smaller customer it's really a pro to have > everything in one system. > > The "perfect" system would allow integration at any point: > - Do it all in Magnolia > - Do it all in a specialized solution only allowing to sign up on a Magnolia > page > - Mix (e.g. sign up and creation of the Mailing in Magnolia, delivery and > monitoring in the external system) If we're serious about sending more than 2 emails at a time from Magnolia, we need some form of queue mechanism, where mails are temporarily queued before being sent - allows for "batches" - and where they go back in case of errors - keeps on sending the next emails when one fails, and allows to re-send or discard the failed ones. >>> We would appreciate your feedback on this: >>> - Do you disagree on the features listed above? >>> - Did anyone already implement some of the stuff? >>> - Do we need to pay attention to something else? >> >> Streamlining and refactoring of the code before major extensions to it might >> be helpful. > > Any part you're thinking of in particular? I don't think there is any specific, "small" target for this; the whole module needs this. ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
