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 &lt;jeremie.bousquet(a)gmail.com&gt; -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

On Thu, Dec 20, 2012 at 12:55 PM, Thomas Delafosse < thomas.delafosse(a)xwiki.com&gt; wrote: Would be nice to start from what Jeremie already started on https://github.com/xwiki-contrib/xwiki-application-mailarchive/tree/master/… it's the same goal, a generic mail component API. -- Thomas Mortagne

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 &lt;vincent(a)massol.net&gt;

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 &lt;jeremie.bousquet(a)gmail.com&gt; -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

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 &lt;thomas.delafosse(a)xwiki.com&gt; wrote:

I've been thinking a bit more on the mailSender component, and here's the APIs I have in mind : The component API would have the following methods : - void prepareMail(String from, String to, String cc, String bcc, String subject) - void addToContent(String contentType, String content) //To add a part to the mail, contentType being the Mime Type of this part - void addAttachment(Attachment file) - int sendMail() //Returns 1 on success and 0 otherwise And the scripting API would have the following : - void prepareMail(String from, String to, String cc, String bcc, String subject) - void addToContent(String contentType, String content) - void addHtml(String content) - void addCalendar(String vCalendar) - int sendMail() - int sendHtmlMail(String from, String to, String subject, String html, String alternativeText) //Simple method for non-experienced users sending a simple html mail { this.mailSender.prepareMail(from, to, null, null, subject) ; this.mailSender.addToContent("text/html", html) ; this.mailSender.addToContent("text/plain", alternativeText); return this.mailSender.sendMail() ; } So, a simple use-case would look something like : {{velocity}} $services.mailSender.prepareMail(&quot;foo(a)bar.fr&quot;r.fr", &quot;foo2(a)bar.fr&quot;r.fr", "", "", "Subject") $services.mailSender.addHtml("<strong>This is an email with a calendar</strong>") $services.mailSender.addCalendar($calendar) $services.mailSender.sendMail() {{/velocity}} What do you think ? Is there anything you think is missing ? In peticular, I'm wondering whether it would be useful to recreate methods similar to the parseRawMessage() and sendMailFromTemplate() methods that were implemented in the former mailSender ? Cheers, Thomas On Thu, Dec 20, 2012 at 7:00 PM, Sergiu Dumitriu &lt;sergiu(a)xwiki.org&gt; wrote:

Ok, so I would rather have a component API like - Mail prepareMail(from, to, cc, bcc, subject) - int sendMail(Mail mail) while the methods addToContent, addHtml, addAttachment, etc... would be directly used from the Mail class. So a use-case would rather be : {{velocity}} $mail = $services.mailSender.prepareMail(from, to,...) $mail.addHtml('<p>Blabla</p>') $mail.addCalendar() $services.mailSender.sendMail($mail) {{/velocity}} Thanks, Thomas On Wed, Dec 26, 2012 at 3:04 PM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote:

On Wed, Dec 26, 2012 at 3:23 PM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: addToContent (String mimeType, String partToAdd) is more generic : you specify the Mime Type of the part you want to add. So addHtml(String s) is just the same as addToContent("text/html", s). But as most of the time you add only Html or text, I was thinking it was better to have a specific method to add an Html part in the scripting API. I can do the same with a addTextContent method. Yes, so for example if you want to have an email with an html part and a calendar part, you call addToContent("text/html", html Text) and then addToContent("text/calendar", calendar Code). It is either a vCalendar or an iCalendar (it is used by Gmail to send invitations). It corresponds to the Mime Type "text/calendar". Here again addCalendar(String calendar) is just the same as addToContent("text/calendar", calendar). It's just to make it easier to use. On Java it would give something like : @Inject private MailSender mailSender Mail mail = this.mailSender.newMail(from,to,subject) ; String htmlCode = "<p>Blabla</p>" ; String calendar = "BEGIN VCALENDAR... END VCALENDAR" ; mail.addToContent("text/html", htmlCode) ; mail.addToContent("text/calendar", calendar) ; this.mailSender.sendMail(mail) ;

On Wed, Dec 26, 2012 at 4:18 PM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: Yes, I add a BodyPart to my global mail multipart every time I call addContent. Yes. Anyway I was already thinking about doing something like that for my "Meetings" application :) Thanks Yes you're right, I can just do Mail mail = new Mail(from, to, subject). I was just getting confused with the components :). Indeed ! I will make an effort on the naming of my methods.

On Fri, Dec 28, 2012 at 9:01 PM, Sergiu Dumitriu &lt;sergiu(a)xwiki.org&gt; wrote: I agree on that point : there are simpler methods such as $services.mailSender.sendHtmlMail(from, to, subject, html, alternative) for people who don't know much about mimeTypes, so it would be a shame to limit this method. So far it's exactly the way my addContent method works. But I can change its name to addMimePart if you prefer. If there is only a text or html part to the mail, I add an alternative text/plain part to the mail, using jSoup to convert the html content into text, if it's what you mean. https://github.com/tdelafosse/mailSender. Feel free to have a look and to tell me if there's things to change / add / enhance. Cheers, Thomas

The advantage of jSoup is that it handles the problems I could have if the html part is not well written, so I was thinking it was more secure to use it than just parsing the "<>" in the html part . But I must admit that I haven't had a close look on the xwiki renderers, and if there are some that do it well, I should probably rather use them... I will give it a closer look tomorrow. Cheers, Thomas On Sun, Jan 6, 2013 at 8:53 AM, Jeremie BOUSQUET &lt;jeremie.bousquet(a)gmail.com > Le 2 janv. 2013 18:44, "Thomas Delafosse" &lt;thomas.delafosse(a)xwiki.com&gt; a > écrit : > > > > On Fri, Dec 28, 2012 at 9:01 PM, Sergiu Dumitriu &lt;sergiu(a)xwiki.org&gt; > > > > > On 12/26/2012 10:18 AM, Vincent Massol wrote: > > > > > > > > On Dec 26, 2012, at 4:01 PM, Thomas Delafosse < > > > thomas.delafosse(a)xwiki.com> > > > > > > >> On Wed, Dec 26, 2012 at 3:23 PM, Vincent Massol &lt;vincent(a)massol.net > > > > > > > >> > > > >>> > > > >>> On Dec 26, 2012, at 3:15 PM, Thomas Delafosse < > > > thomas.delafosse(a)xwiki.com&gt; > > > >>> > > >>> > > > >>>> Ok, so I would rather have a component API like > > > >>>> > > > >>>> - Mail prepareMail(from, to, cc, bcc, subject) > > > >>> > > > >>> createMail is better than prepareMail IMO. > > > >>> > > > >>> I'd make the cc and bcc not part of the constructor and instead > move > > > them > > > >>> as setters since they're optional. > > > >>> > > > >>>> - int sendMail(Mail mail) > > > >>> > > > >>> Either that or add a send() method in Mail. > > > >>> > > > >>>> while the methods addToContent, addHtml, addAttachment, etc... > would > > > be > > > >>>> directly used from the Mail class. > > > >>> > > > >>> I don't understand what addToContent is and what different it has > to > > > >>> addHtml. > > > >>> > > > >> > > > >> addToContent (String mimeType, String partToAdd) is more generic : > you > > > >> specify the Mime Type of the part you want to add. So addHtml(String > s) > > > is > > > >> just the same as addToContent("text/html", s). But as most of the > time > > > you > > > >> add only Html or text, I was thinking it was better to have a > specific > > > >> method to add an Html part in the scripting API. I can do the same > with > > > a > > > >> addTextContent method. > > > > > > > > I think I prefer addContent instead of addToContent. > > > > > > > > So just to be sure, doing the following will work: > > > > > > > > addContent("content1", "text") > > > > addContent("content2", "text") > > > > addContent("content3", "html") > > > > > > > > right? > > > > > > > > It's going to create a multipart email? > > > > > > > > I think a single addContent method is good enough, passing an enum as > > > the second parameter (the mimetype). Enums are magically constructed > from > > > velocity with our custom uberspector. > > > > > > -1 for enums. That limits the possible content types we can add. > > > > > > > I agree on that point : there are simpler methods such as > > $services.mailSender.sendHtmlMail(from, to, subject, html, alternative) > for > > people who don't know much about mimeTypes, so it would be a shame to > limit > > this method. > > > > > > > > I prefer: > > > > > > addMimePart(String content, string mimeType) > > > > > > > > So far it's exactly the way my addContent method works. But I can change > > its name to addMimePart if you prefer. > > > > > > > There's also a MimePart in the standard javax.mail library, and we > could > > > actually use this one, since it's more standard, and more flexible: > > > > > > > http://javamail.kenai.com/nonav/javadocs/javax/mail/internet/MimePart.html > > > > > > > > > > > http://javamail.kenai.com/nonav/javadocs/javax/mail/internet/MimeBodyPart.h… > > > > > > But this might be a bit too verbose and complex to use. > > > > > > I hope that the implementation will be smart enough to send a plain > > > message when only one body part (of type text or html) is present. > > > > > > > > If there is only a text or html part to the mail, I add an alternative > > text/plain part to the mail, using jSoup to convert the html content into > > text, if it's what you mean. > > On mail reader side, I used xwiki parsers/renderers to convert html to > plain text. What is added value of jsoup ? > > > > > >>> Can I call addContent several times? > > > >>> > > > >> > > > >> Yes, so for example if you want to have an email with an html part > and a > > > >> calendar part, you call addToContent("text/html", html Text) and > then > > > >> addToContent("text/calendar", calendar Code). > > > >> > > > >> > > > >>> > > > >>>> So a use-case would rather be : > > > >>>> {{velocity}} > > > >>>> $mail = $services.mailSender.prepareMail(from, to,...) > > > >>>> $mail.addHtml('<p>Blabla</p>') > > > >>> > > > >>> addHTMLContent would be nicer. So you need also a addTextContent? > > > >>> why not have an addContent(String, boolean isHTML) > > > >>> or a more generic addContent(String, String mimeType) > > > >>> or both > > > >>> > > > >>>> $mail.addCalendar() > > > >>> > > > >>> What is a calendar? > > > >>> > > > >> > > > >> It is either a vCalendar or an iCalendar (it is used by Gmail to > send > > > >> invitations). It corresponds to the Mime Type "text/calendar". Here > > > again > > > >> addCalendar(String calendar) is just the same as > > > >> addToContent("text/calendar", calendar). It's just to make it easier > to > > > >> use. > > > > > > > > ok. So I think in the future we could add some calendar helper that > will > > > create the calendar string information. > > > > > > -1 for a specific addCalendar method. Why not addVCard, addImage, > > > addPDF, addDoc and so on? This makes a stuffed API, where anything that > > > doesn't have a dedicated API method will feel like a second-class > > > citizen. > > > > > > > > For now this is good enough IMO: > > > > addContent("calendar info content as per RFC 2445", "calendar") > > > > > > > > And then later on something like: > > > > > > > > addContent($mailsender.createCalendarMimeTypeData(param1, param2, > ….), > > > "calendar") > > > > > > > >>> You should also show an example when using the Java API. > > > >>> > > > >> > > > >> On Java it would give something like : > > > >> > > > >> @Inject > > > >> private MailSender mailSender > > > >> > > > >> Mail mail = this.mailSender.newMail(from,to,subject) ; > > > > > > > > I don't like this too much. Why not use a constructor on the Mail > object? > > > > > > Constructors are bad, in a component-based world. I'd rather have the > > > Mail object an interface, with an internal implementation used by the > > > MailSender implementation. > > > > > > > (The other option is a perlookup component is you really need to have > > > some other components injected in the Mail object; in that case you'll > need > > > setters to from/to/subject since we currently don't support constructor > > > injection). > > > > > > > >> String htmlCode = "<p>Blabla</p>" ; > > > >> String calendar = "BEGIN VCALENDAR... END VCALENDAR" ; > > > >> mail.addToContent("text/html", htmlCode) ; > > > >> mail.addToContent("text/calendar", calendar) ; > > > >> this.mailSender.sendMail(mail) ; > > > > > > > > why sendMail and not send? We're in a MailSender component so we know > > > we're sending mail already ;) > > > > > > +1 for send. > > > > > > By the way, I've put a first version of my component on github : > > https://github.com/tdelafosse/mailSender. Feel free to have a look and > to > > tell me if there's things to change / add / enhance. > > > > Cheers, > > > > Thomas > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs >

On Mon, Jan 7, 2013 at 12:12 AM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: Plus de HTML parser is very important so the more we test it the better. -- Thomas Mortagne

On Wed, Feb 13, 2013 at 2:40 PM, Jeremie BOUSQUET < jeremie.bousquet(a)gmail.com&gt; wrote: Yes, this is multipart/alternative content I create Indeed with what I have implemented so far, this has very little meaning. I considered that people that were going to use addContent and not directly one of the method like $services.mailSender.sendMail(to, html, alternative text) would be aware of that (of course this should be explicitly said in the doc). But I agree that we could perhaps consider letting them choose between multipart/alternative and multipart/mixed for example. I'm just afraid that it would make the component harder to understand and to use. When I have a text/html mime part, I parse it for finding things like src :cid and create a multipart/related part in order to embed the image in the HTML. So I guess it's fine from this point of view. By the way, I've just put my current mailSender code on a contrib repo : https://github.com/xwiki-contrib/xwiki-platform-mail. I should still clear up a few things in it (had to make some strange thing to get rid of class fan out issues... I would take care of it as soon as I have time to, hopefully next week) before it is publishable but it is supposed to work (I tested it locally) and it would at least enable you to see how things are done. Don't hesitate to comment it, and let me know what you think should be changed ! Using mail Templates enables you to include some Wiki content in it. Perhaps it is what the Newsletter application uses ? Cheers, Thomas