Re: [xwiki-devs] Future of mailsender plugin

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,

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

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,

"internal" headers stripped) instead of creating/extending a flat API

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 &lt;vincent(a)massol.net&gt; > > On Dec 20, 2012, at 1:35 PM, Thomas Mortagne <

cc, > >> String bcc, String subject, String[] contents, List<Attachment> > >> attachments) (1) > >> where contents would be a string array containing all the contents

be > >> embed in the mail (text, html but also a vCalendar for example)

> 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

> thus > >> allowing us to parse it. For example we could imagine having

cc, > >> String bcc, String subject, String body, List<Attachment>

> with > >> body = "{{html}}HTML code{{/html}} {{calendar}}Calendar > code{{/calendar}}" > >> (2) or even > >> body = "{{mailPart type='text/html'}}HTML code{{/mailPart}}

> >> type="text/calendar"}}Calendar code{{/mailPart}}" (3). > >> This would be easier to use ((2) most of all), but probably

> > 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 &lt;ludovic(a)xwiki.com&gt; > wrote: > >> > >>> Hi Jeremie and all, > >>> > >>> Note that currently mailsender is used quite a lot by standard

> >>> 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

> code > >>> that generates vcalendar invitations because it could be used in

rewriting a > >>> mail code that handles vcalendar is tough: > >>> > >>> So what would be the approach to add a vcalendar part in emails

by > >> the > >>> current mailsender ? Can I propose my patches that add the

> API: > >>> > >>> public int sendHtmlMessage(String from, String to, String cc,

> 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,

> 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,

change > >> the > >>> content type of the emails from these APIs > >>> > >>> Ludovic > >>> > >>> > >>> > >>> > >>> > >>> 2012/11/23 Jeremie BOUSQUET &lt;jeremie.bousquet(a)gmail.com&gt; > >>> > >>>> Hi Ludovic, > >>>> > >>>> If I may invite myself in the discussion, I have the same

> >>>> concerning the mail archive app I'm writing, in which I plan to

a > >>>> "reply" feature on one side, and on the other side add management

> >>>> vcalendar parts in incoming emails. Naturally, it would then be

> 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

> >>>> behind, and providing facilities to parse emails headers and

> and > >>> why > >>>> not send emails. For now it "knows" how to read and compute most > emails > >>>> content (text, html, headers, attachments, attached emails),

> 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

for a > >>>> "mail" and/or "mailsender" component to be shared for xwiki and

multipart but > >> it > >>>>> does not really sound right to do that since we should support

> >> part > >>>> of > >>>>> any content type, but this is a bigger refactoring. > >>>>> > >>>>> I was wondering what the future is for the mailsender plugin. Do

plan sent feature _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs