my (personal) take on this ... inlined On Jun 18, 2010, at 11:17 AM, Will Scheidegger wrote:
> > We need some additional features for a project of ours... but think they > could be useful for all. Therefore we're planning to extend the mail module. > Now before we start hacking I wanted to coordinate our efforts here - > especially since we're currently working on Mag 4.2.3 code base. > > What we intend to add: > > - a WebPageMail class extending MgnlPageEmail to allow sending the contents > of an arbitrary URL > This currently does not work with MgnlPageEmail because it relies on having a > URL which contains MgnlContext.contextPath() Sounds good, patch for this would be welcome > > - inclusion of JavaScript files as it's done with CSS files: What do you > think? Waste of time since JavaScript is not supported well enough in the > email clients? why not, but optional and disabled by default (content with embedded javascript will be anyway blocked by many clients, in difference to embedded css) > > - a parameter to control the inclusion of images as attachements, CSS and > JavaScripts in the head probably one param for each no? > > - a SerialMailCommand extending MailCommand supporting the production and > delivery of serial mails > - personalized serial mails would need to first set the body and then > process freemarker tags in the body for each mail (and of course also in the > subject) > - configurations settings for the mail delivery to be stored and used > (e.g. how many mails to be sent in a batch, how big of a break between each > batch, reconnection to the mail server after how many 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. 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). > > And I could think of more stuff, but that should do it for starters. > > 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. > > Thanks! > -will > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- - Best regards, Jan Haderka, PhD. Magnolia International Ltd. http://www.magnolia-cms.com You should join us at Magnolia Conference 2010: http://www.magnolia-cms.com/conference http://twitter.com/magnolia_cms http://facebook.com/Magnolia -------------------------------------- Magnolia® - Simple Open-Source Content Management ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
