Be careful to not mix the Java API with the scripting API. Both API need to be different and the best adapted for the language.
Thanks -Vincent On Dec 20, 2012, at 4:01 PM, Thomas Delafosse <[email protected]> wrote: > 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
