I agree. I would try to recreate something like the current mailsender.sendHtmlMessage(...) and sendTextMessage(...) from the components we would develop.
Thomas On Thu, Dec 20, 2012 at 3:48 PM, Ludovic Dubost <[email protected]> wrote: > Hi, > > While it's great to have a object oriented API to compose a complex email, > I believe for velocity and a set of simple use cases it's also good to > have at least in the scripting API some simple direct APIs like we have in > the current mailsender. It reduces the number of lines written for simple > text or html email > > Ludovic > > > 2012/12/20 Jeremie BOUSQUET <[email protected]> > > > I even think there could be 3 modules for this :) And a unique script > > service for "pure" mails manipulation... > > Depends on what level of API is wanted. > > > > Considering what I started and what I would find nice as a target, > possible > > use-case would look like the following: > > > > {{velocity}} > > > > ## Sending a mail > > > > #set($mail = $services.mail.newMail("sender", "from", "to", "cc", > > "subject")) > > $mail.addText("bla bla bla") > > $mail.addHtml("<html/>") > > $mail.addCalendar($services.mail.newCalendar("begin date", "end date", > > "subject", ...)) > > $mail.addContent("content type", "content") > > > > $mail.send() > > ## or > > $mail.send(host, port, protocol, ...) > > ## or > > $services.mail.send($mail, host, port, protocol...) > > > > ## Reading a mail > > > > #set($mails = $services.mail.fetch(host, port, protocol, ...)) > > #set($mail = $mails[0]) > > $mail.from, $mail.to, $mail.cc, $mail.text, $mail.html ... > > > > ## Resending / Replying > > > > #set($mails = $services.mail.fetch(host, port, protocol, ...)) > > #set($mail = $mails[0]) > > #set($newMail = $services.mail.newReply($mail)) ## from --> to, etc. > > > > $newMail.send() > > ## or > > $newMail.send(host, port, protocol, ...) > > ## or > > $services.mail.send($newMail, host, port, protocol, ...) > > > > {{/velocity}} > > > > In that case there would be as components something like : > > mail-commons-api, mail-sender-api, mail-reader-api. > > If script services are distinct, the above would be replaced by: > > $services.mail.newMail(...) > > $services.mail.newReply(...) > > $services.mailSender.send(...) > > $services.mailReader.fetch(...) (or read() of course) > > ... but I'm not sure it really adds value to differentiate. > > The inner javamail "Message" would never be publicly exposed, while > > authorizing easy manipulations. > > > > For now what I wrote is a mixed-bag of what is above, and only for > reading. > > But I really believe that: > > - there's an added value to "materialize" a mail in specific object(s) > > (MailItem.java and MailContent.java in my work in progress components, > with > > "internal" headers stripped) instead of creating/extending a flat API > with > > numerous parameters > > - those objects should be shared between the sender and the reader > > components > > > > For now my current API is more: > > Message fetch(host, port, protocol, ...) > > MailItem parseHeaders(Message message) > > MailContent parseContent(Message message) > > ... because it's usually a good thing to lazily load message body parts. > > > > WDYT ? > > > > BR, > > Jeremie > > > > > > > > 2012/12/20 Vincent Massol <[email protected]> > > > > > > > > On Dec 20, 2012, at 1:35 PM, Thomas Mortagne < > [email protected]> > > > wrote: > > > > > > > On Thu, Dec 20, 2012 at 12:55 PM, Thomas Delafosse < > > > > [email protected]> wrote: > > > > > > > >> Hi all, > > > >> > > > >> I would be happy to work on the mailSender plugin. > > > >> I propose to make it a component and add it a few functionalities. > > > Namely, > > > >> I was thinking about adding an API like: > > > >> public int sendMultiContentMessage (String from, String to, String > > cc, > > > >> String bcc, String subject, String[] contents, List<Attachment> > > > >> attachments) (1) > > > >> where contents would be a string array containing all the contents > to > > be > > > >> embed in the mail (text, html but also a vCalendar for example) > along > > > with > > > >> their MIME type. > > > >> So for example, if you want to send a mail containing some html part > > > and a > > > >> vCalendar, "contents" would look something like : > > > >> contents = ['text/html', Your Html code, 'text/calendar', Your > > > vCalendar] . > > > >> > > > >> Another way to achieve this would be to use a single String "body" > > > instead > > > >> of "contents", with a specific syntax indicating each part MIME > type, > > > thus > > > >> allowing us to parse it. For example we could imagine having > something > > > like > > > >> : > > > >> public int sendMultiContentMessage (String from, String to, String > > cc, > > > >> String bcc, String subject, String body, List<Attachment> > attachments) > > > with > > > >> body = "{{html}}HTML code{{/html}} {{calendar}}Calendar > > > code{{/calendar}}" > > > >> (2) or even > > > >> body = "{{mailPart type='text/html'}}HTML code{{/mailPart}} > {{mailPart > > > >> type="text/calendar"}}Calendar code{{/mailPart}}" (3). > > > >> This would be easier to use ((2) most of all), but probably > trickier, > > > >> slower and for (2), less flexible. > > > >> > > > >> WDYT ? And of course, if there is anything else you would like to > > > change in > > > >> the mailSender, let me know ! > > > >> > > > > > > > > Would be nice to start from what Jeremie already started on > > > > > > > > > > https://github.com/xwiki-contrib/xwiki-application-mailarchive/tree/master/xwiki-contrib-mailsince > > > > it's the same goal, a generic mail component API. > > > > > > I think it's different: one is for mail sending, the other for mail > > > reading. I agree with Ludovic that we should have 2 modules for this. > > > > > > Thanks > > > -Vincent > > > > > > >> Thomas > > > >> > > > >> On Wed, Nov 28, 2012 at 3:01 PM, Ludovic Dubost <[email protected]> > > > wrote: > > > >> > > > >>> Hi Jeremie and all, > > > >>> > > > >>> Note that currently mailsender is used quite a lot by standard > XWiki > > > >>> Enterprise features like "send page by email", "invitation", > > > >>> "registration". > > > >>> I agree that the mailsender code could be merged with your own > > > component > > > >>> that currently handles reading emails. > > > >>> > > > >>> Any other opinion on the mail I sent before. I'd like to publish > the > > > code > > > >>> that generates vcalendar invitations because it could be used in > many > > > >> areas > > > >>> but without the mailsender modifications it cannot work and > > rewriting a > > > >>> mail code that handles vcalendar is tough: > > > >>> > > > >>> So what would be the approach to add a vcalendar part in emails > sent > > by > > > >> the > > > >>> current mailsender ? Can I propose my patches that add the > following > > > API: > > > >>> > > > >>> public int sendHtmlMessage(String from, String to, String cc, > String > > > bcc, > > > >>> String subject, String body, > > > >>> String alternative, String calendar, List<Attachment> > > > >> attachments) > > > >>> > > > >>> which is derived from > > > >>> > > > >>> public int sendHtmlMessage(String from, String to, String cc, > String > > > bcc, > > > >>> String subject, String body, > > > >>> String alternative, List<Attachment> attachments) > > > >>> > > > >>> Note that this API should actually be: > > > >>> > > > >>> public int sendHtmlMessage(String from, String to, String cc, > String > > > bcc, > > > >>> String subject, String html, > > > >>> String alternativeText, List<Attachment> attachments) > > > >>> > > > >>> As this is the way the fields are used since there is no way to > > change > > > >> the > > > >>> content type of the emails from these APIs > > > >>> > > > >>> Ludovic > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> 2012/11/23 Jeremie BOUSQUET <[email protected]> > > > >>> > > > >>>> Hi Ludovic, > > > >>>> > > > >>>> If I may invite myself in the discussion, I have the same > questions > > > >>>> concerning the mail archive app I'm writing, in which I plan to > add > > a > > > >>>> "reply" feature on one side, and on the other side add management > of > > > >>>> vcalendar parts in incoming emails. Naturally, it would then be > nice > > > to > > > >>> be > > > >>>> able to send vcalendar as an email part (or any type of part). > > > >>>> > > > >>>> For now there's no "reply" feature so of course I do not use the > > > >>> mailsender > > > >>>> plugin. But there's the beginning of a "mail" component, for now > > > >>> dedicated > > > >>>> to the mail archive app, and obviously aiming at hiding javamail > api > > > >>>> behind, and providing facilities to parse emails headers and > parts, > > > and > > > >>> why > > > >>>> not send emails. For now it "knows" how to read and compute most > > > emails > > > >>>> content (text, html, headers, attachments, attached emails), > though > > > has > > > >>>> same limitation (including vcalendar). > > > >>>> > > > >>>> Currently the api is like that, but is quite draft and unstable > > > (mostly > > > >>> the > > > >>>> update/create*Page that are not even implemented, and IMO should > be > > > >>>> removed): > > > >>>> > > > >>>> > > > >>> > > > >> > > > > > > https://github.com/xwiki-contrib/xwiki-application-mailarchive/blob/master/xwiki-contrib-mail/src/main/java/org/xwiki/contrib/mail/IMailComponent.java > > > >>>> What's available from parsed mail body is: > > > >>>> > > > >>>> > > > >>> > > > >> > > > > > > https://github.com/xwiki-contrib/xwiki-application-mailarchive/blob/master/xwiki-contrib-mail/src/main/java/org/xwiki/contrib/mail/MailContent.java > > > >>>> > > > >>>> Obviously, when all that reaches a final state, it would be nice > > for a > > > >>>> "mail" and/or "mailsender" component to be shared for xwiki and > the > > > >> mail > > > >>>> archive app (and whoever wants to bother with mails) needs, > > > >>>> > > > >>>> That was for your information, > > > >>>> > > > >>>> BR, > > > >>>> Jeremie > > > >>>> > > > >>>> > > > >>>> > > > >>>> 2012/11/23 Ludovic Dubost <[email protected]> > > > >>>> > > > >>>>> Hi, > > > >>>>> > > > >>>>> I wanted to discuss about the future of the mailsender plugin ? > > > >>>>> > > > >>>>> I've been working on a small tool to be able to send a Calendar > > > >>>> Invitation > > > >>>>> by email from a Meeting Notes AppWithinMinutes application and I > > > >> found > > > >>>> some > > > >>>>> limitation in the mailsender plugin, namely you cannot add > > multipart > > > >>>>> alternative email parts in addition to the text and html parts > > > >> already > > > >>>>> supported by the plugin. > > > >>>>> > > > >>>>> I was able to hack the mailsender plugin to add a vcalendar part > > but > > > >> it > > > >>>>> does not really sound right to do that since we should support > any > > > >> part > > > >>>> of > > > >>>>> any content type, but this is a bigger refactoring. > > > >>>>> > > > >>>>> I was wondering what the future is for the mailsender plugin. Do > we > > > >>> plan > > > >>>> to > > > >>>>> make it a component and keep the same functionality ? Is there a > > plan > > > >>> for > > > >>>>> an alternative component ? > > > >>>>> > > > >>>>> And what would be the approach to add a vcalendar part in emails > > sent > > > >>> by > > > >>>>> the current mailsender ? This would be needed to support the > > feature > > > >> of > > > >>>>> sending invitation emails which would be very powerfull. > > > >>>>> > > > >>>>> Ludovic > > > >>>>> > > > >>>>> -- > > > _______________________________________________ > > > devs mailing list > > > [email protected] > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > Ludovic Dubost > Founder and CEO > Blog: http://blog.ludovic.org/ > XWiki: http://www.xwiki.com > Skype: ldubost GTalk: ldubost > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
