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 ! 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/x...

...

What's available from parsed mail body is:

https://github.com/xwiki-contrib/xwiki-application-mailarchive/blob/master/x...

...

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

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

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

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/x... 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/x...

...

...

What's available from parsed mail body is:

https://github.com/xwiki-contrib/xwiki-application-mailarchive/blob/master/x...

...

...

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

--

I like the idea of materializing a mail in specific objects. This is indeed easier for the user to use something like $mail.addHtml and $mail.addContent than having a complicated API as I proposed. All the same I'm ok for sharing these objects between the sender and reader components. Let me think a bit more about all this, and I'll let you know as soon as I have a more precise idea of what exactly I'm going to do and how I'm going to do it. Cheers, Thomas On Thu, Dec 20, 2012 at 3:17 PM, Jeremie BOUSQUET < [email protected]> wrote:

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/x...

...

...

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/x...

...

...

...

...

...

What's available from parsed mail body is:

https://github.com/xwiki-contrib/xwiki-application-mailarchive/blob/master/x...

...

...

...

...

...

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

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/x...

...

...

...

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/x...

...

...

...

...

...

> What's available from parsed mail body is: > >

https://github.com/xwiki-contrib/xwiki-application-mailarchive/blob/master/x...

...

...

...

...

...

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

On 12/20/2012 06:55 AM, Thomas Delafosse 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)

Methods with too many arguments are not recommended. It even breaks our checkstyle, which allows at most 7 parameters (which I think is too much, anyway). Listing possible mail tokens is bad, since in most cases not all of them are needed, and in some cases others will be needed with no way of specifying them, other than writing the whole message including headers by hand. Either use a typed object, or a generic map.

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

This is an untyped convention. You're hoping that all users will read the documentation and know that they're supposed to provide pairs of values, MIME + content. That's not a nice thing to do. A list of typed objects would be better, since it doesn't allow mistakes.

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.

I don't like this either, it's even more error prone. Java is an OOP language, use good OOP design as much as possible.

WDYT ? And of course, if there is anything else you would like to change in the mailSender, let me know !

Thomas

-- Sergiu Dumitriu http://purl.org/net/sergiu

Hi Thomas, On Dec 26, 2012, at 2:58 PM, Thomas Delafosse <[email protected]> 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("[email protected]", "[email protected]", "", "", "Subject") $services.mailSender.addHtml("<strong>This is an email with a calendar</strong>") $services.mailSender.addCalendar($calendar) $services.mailSender.sendMail() {{/velocity}}

This is not very good because you're making the service stateful and services mist absolutely be stateless. They need to be able to be used by several threads and not hold any state. Your API calls must return some object if you want to have several calls. Thanks -Vincent

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 <[email protected]> wrote:

...

On 12/20/2012 06:55 AM, Thomas Delafosse 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)

Methods with too many arguments are not recommended. It even breaks our checkstyle, which allows at most 7 parameters (which I think is too much, anyway). Listing possible mail tokens is bad, since in most cases not all of them are needed, and in some cases others will be needed with no way of specifying them, other than writing the whole message including headers by hand.

Either use a typed object, or a generic map.

...

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

This is an untyped convention. You're hoping that all users will read the documentation and know that they're supposed to provide pairs of values, MIME + content. That's not a nice thing to do. A list of typed objects would be better, since it doesn't allow mistakes.

...

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.

I don't like this either, it's even more error prone.

Java is an OOP language, use good OOP design as much as possible.

...

WDYT ? And of course, if there is anything else you would like to change in the mailSender, let me know !

Thomas

-- Sergiu Dumitriu http://purl.org/net/sergiu _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Dec 26, 2012, at 3:15 PM, Thomas Delafosse <[email protected]> wrote:

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. Can I call addContent several times?

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? You should also show an example when using the Java API. Thanks -Vincent

$services.mailSender.sendMail($mail) {{/velocity}}

Thanks,

Thomas

On Wed, Dec 26, 2012 at 3:04 PM, Vincent Massol <[email protected]> wrote:

...

Hi Thomas,

On Dec 26, 2012, at 2:58 PM, Thomas Delafosse <[email protected]> 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("[email protected]", "[email protected]", "", "", "Subject") $services.mailSender.addHtml("<strong>This is an email with a calendar</strong>") $services.mailSender.addCalendar($calendar) $services.mailSender.sendMail() {{/velocity}}

This is not very good because you're making the service stateful and services mist absolutely be stateless. They need to be able to be used by several threads and not hold any state. Your API calls must return some object if you want to have several calls.

Thanks -Vincent

...

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 <[email protected]> wrote:

...

On 12/20/2012 06:55 AM, Thomas Delafosse 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)

Methods with too many arguments are not recommended. It even breaks our checkstyle, which allows at most 7 parameters (which I think is too much, anyway). Listing possible mail tokens is bad, since in most cases not all of them are needed, and in some cases others will be needed with no way of specifying them, other than writing the whole message including headers by hand.

Either use a typed object, or a generic map.

...

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

This is an untyped convention. You're hoping that all users will read the documentation and know that they're supposed to provide pairs of values, MIME + content. That's not a nice thing to do. A list of typed objects would be better, since it doesn't allow mistakes.

...

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.

I don't like this either, it's even more error prone.

Java is an OOP language, use good OOP design as much as possible.

...

WDYT ? And of course, if there is anything else you would like to change in the mailSender, let me know !

Thomas

On Dec 26, 2012, at 4:01 PM, Thomas Delafosse <[email protected]> wrote:

On Wed, Dec 26, 2012 at 3:23 PM, Vincent Massol <[email protected]> wrote:

...

On Dec 26, 2012, at 3:15 PM, Thomas Delafosse <[email protected]> wrote:

...

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.

...

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. 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? (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 ;) Thanks -Vincent

...

Thanks -Vincent

...

$services.mailSender.sendMail($mail) {{/velocity}}

Thanks,

Thomas

On Wed, Dec 26, 2012 at 3:04 PM, Vincent Massol <[email protected]> wrote:

...

Hi Thomas,

On Dec 26, 2012, at 2:58 PM, Thomas Delafosse < [email protected]> 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("[email protected]", "[email protected]", "", "", "Subject") $services.mailSender.addHtml("<strong>This is an email with a calendar</strong>") $services.mailSender.addCalendar($calendar) $services.mailSender.sendMail() {{/velocity}}

This is not very good because you're making the service stateful and services mist absolutely be stateless. They need to be able to be used by several threads and not hold any state. Your API calls must return some object if you want to have several calls.

Thanks -Vincent

...

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 <[email protected]> wrote:

...

On 12/20/2012 06:55 AM, Thomas Delafosse 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)

Methods with too many arguments are not recommended. It even breaks our checkstyle, which allows at most 7 parameters (which I think is too much, anyway). Listing possible mail tokens is bad, since in most cases not all of them are needed, and in some cases others will be needed with no way of specifying them, other than writing the whole message including headers by hand.

Either use a typed object, or a generic map.

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

This is an untyped convention. You're hoping that all users will read the documentation and know that they're supposed to provide pairs of values, MIME + content. That's not a nice thing to do. A list of typed objects would be better, since it doesn't allow mistakes.

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

I don't like this either, it's even more error prone.

Java is an OOP language, use good OOP design as much as possible.

> WDYT ? And of course, if there is anything else you would like to change in > the mailSender, let me know ! > > Thomas

On 12/26/2012 10:18 AM, Vincent Massol wrote:

On Dec 26, 2012, at 4:01 PM, Thomas Delafosse <[email protected]> wrote:

...

On Wed, Dec 26, 2012 at 3:23 PM, Vincent Massol <[email protected]> wrote:

...

On Dec 26, 2012, at 3:15 PM, Thomas Delafosse <[email protected]> wrote:

...

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 prefer: addMimePart(String content, string mimeType) 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.ht... 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.

...

...

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.

Thanks -Vincent

...

...

Thanks -Vincent

...

$services.mailSender.sendMail($mail) {{/velocity}}

Thanks,

Thomas

On Wed, Dec 26, 2012 at 3:04 PM, Vincent Massol <[email protected]> wrote:

...

Hi Thomas,

On Dec 26, 2012, at 2:58 PM, Thomas Delafosse < [email protected]> 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("[email protected]", "[email protected]", "", "", "Subject") $services.mailSender.addHtml("<strong>This is an email with a calendar</strong>") $services.mailSender.addCalendar($calendar) $services.mailSender.sendMail() {{/velocity}}

This is not very good because you're making the service stateful and services mist absolutely be stateless. They need to be able to be used by several threads and not hold any state. Your API calls must return some object if you want to have several calls.

Thanks -Vincent

...

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 <[email protected]> wrote:

> On 12/20/2012 06:55 AM, Thomas Delafosse 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) > > Methods with too many arguments are not recommended. It even breaks our > checkstyle, which allows at most 7 parameters (which I think is too > much, anyway). Listing possible mail tokens is bad, since in most cases > not all of them are needed, and in some cases others will be needed with > no way of specifying them, other than writing the whole message > including headers by hand. > > Either use a typed object, or a generic map. > >> 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] . > > This is an untyped convention. You're hoping that all users will read > the documentation and know that they're supposed to provide pairs of > values, MIME + content. That's not a nice thing to do. A list of typed > objects would be better, since it doesn't allow mistakes. > >> 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. > > I don't like this either, it's even more error prone. > > Java is an OOP language, use good OOP design as much as possible. > >> WDYT ? And of course, if there is anything else you would like to change > in >> the mailSender, let me know ! >> >> Thomas

-- Sergiu Dumitriu http://purl.org/net/sergiu/

Le 2 janv. 2013 18:44, "Thomas Delafosse" <[email protected]> a écrit :

On Fri, Dec 28, 2012 at 9:01 PM, Sergiu Dumitriu <[email protected]> wrote:

...

On 12/26/2012 10:18 AM, Vincent Massol wrote:

...

On Dec 26, 2012, at 4:01 PM, Thomas Delafosse <

[email protected]> wrote:

...

...

On Wed, Dec 26, 2012 at 3:23 PM, Vincent Massol <[email protected]>

wrote:

...

...

...

On Dec 26, 2012, at 3:15 PM, Thomas Delafosse <

[email protected]>

...

...

wrote:

...

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

...

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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Jan 6, 2013, at 10:54 PM, Thomas Delafosse <[email protected]> wrote:

The advantage of jSoup is that it handles the problems I could have if the html part is not well written,

Actually this is exactly what the XWiki HTML parser does too :) I really think you should use our parser. Thanks -Vincent

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 <[email protected]

...

wrote:

...

Le 2 janv. 2013 18:44, "Thomas Delafosse" <[email protected]> a écrit :

...

On Fri, Dec 28, 2012 at 9:01 PM, Sergiu Dumitriu <[email protected]>

wrote:

...

...

On 12/26/2012 10:18 AM, Vincent Massol wrote:

...

On Dec 26, 2012, at 4:01 PM, Thomas Delafosse <

[email protected]> wrote:

...

...

On Wed, Dec 26, 2012 at 3:23 PM, Vincent Massol <[email protected]

...

wrote:

...

...

> > On Dec 26, 2012, at 3:15 PM, Thomas Delafosse <

[email protected]>

...

> wrote: > >> 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.ht...

...

...

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

Hi, Reviving this thread, because I wonder how multiparts are managed ... More precisely, nowhere in current mailsender API do we choose the type of multipart to manage (ie, multipart/mixed, multipart/alternative...). From what is said above, and the api signatures, it seems that by default the component will generate mails with multipart/alternative content, which may be most common use-case. If it's multipart/alternative, then calling: $mail.addContent("text1", "plain/text") $mail.addContent("text2", "plain/text") $mail.addContent("text3", "plain/html") ... has very little meaning. A multipart alternative is supposed to present alternative representations of the same information, most usual use-case being to provide text and html parts. The client is supposed to display the last part he can handle (ie, pure text client would display the text part, and html capable client will display the html part). When there are several calls to addContent(...) for the same content type, is provided text appended to content already present in existing part ? Ie, in sample above, I would get an email with a plain/text part containing "text1text2" and an html part with "text3" ? If text/plain parts are added instead of concatenated, then in sample below, it would mean that "text2" would obliterate "text1" added before, as it will maybe never be displayed by the client (depending on how the client interprets this case). Another thing, when you add html content to an email, it's usually for its better formatting features compared to plain text. A common use-case (for example, if you want to send a newsletter), is to include some images in the html page sent. To do that, you can't just provide the html content, then some attached images. Doing that you can only send an html page (without inline images) and images attached. To send an html document with inline image, you need to send a multipart/related, instead of a "text/html" part, and generate content-ids for each image/attachment. Is it managed by the mail sender ? By the way it would be quite nice, to be able to round-trip between an XWiki page content (html) and a multipart/related part. I wonder how it is managed by Newsletter Application... Note: concerning the "mail parser" implemented in Mail Archive app, currently, it does not differentiate multipart/related, multipart/alternative and multipart/mixed. The same process applies: all "text/html" parts are parsed into a unique concatenated html content, all "text/plain" parts are parsed into a unique concatenated pure text content. If some attachments have content-ids, their reference are replaced in the html content by a link to proper attached file. This almost respects RFC1341, in that it almost considers all multiparts as "mixed" (but not in sequence, as text and html are grouped together). The resulting display is fine in 99,99% of cases, as far as I tested. BR, Jeremie 2013/1/7 Thomas Mortagne <[email protected]>

On Mon, Jan 7, 2013 at 12:12 AM, Vincent Massol <[email protected]> wrote:

...

On Jan 6, 2013, at 10:54 PM, Thomas Delafosse <

[email protected]> wrote:

...

...

The advantage of jSoup is that it handles the problems I could have if

the

...

...

html part is not well written,

Actually this is exactly what the XWiki HTML parser does too :)

I really think you should use our parser.

Plus de HTML parser is very important so the more we test it the better.

...

Thanks -Vincent

...

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 <

[email protected]

...

...

wrote:

...

Le 2 janv. 2013 18:44, "Thomas Delafosse" <[email protected]> a écrit :

...

On Fri, Dec 28, 2012 at 9:01 PM, Sergiu Dumitriu <[email protected]>

wrote:

...

...

On 12/26/2012 10:18 AM, Vincent Massol wrote: > > On Dec 26, 2012, at 4:01 PM, Thomas Delafosse < [email protected]> wrote: > >> On Wed, Dec 26, 2012 at 3:23 PM, Vincent Massol <

[email protected]

...

...

wrote: >> >>> >>> On Dec 26, 2012, at 3:15 PM, Thomas Delafosse < [email protected]> >>> wrote: >>> >>>> 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.ht...

...

...

...

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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

2013/2/13 Thomas Delafosse <[email protected]>

On Wed, Feb 13, 2013 at 2:40 PM, Jeremie BOUSQUET < [email protected]> wrote:

...

Hi,

Reviving this thread, because I wonder how multiparts are managed ... More precisely, nowhere in current mailsender API do we choose the type of multipart to manage (ie, multipart/mixed, multipart/alternative...). From what is said above, and the api signatures, it seems that by default the component will generate mails with multipart/alternative content, which may be most common use-case.

Yes, this is multipart/alternative content I create

...

If it's multipart/alternative, then calling: $mail.addContent("text1", "plain/text") $mail.addContent("text2", "plain/text") $mail.addContent("text3", "plain/html") ... has very little meaning. A multipart alternative is supposed to

present

...

alternative representations of the same information, most usual use-case being to provide text and html parts. The client is supposed to display the last part he can handle (ie, pure text client would display the text part, and html capable client will display the html part).

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.

I agree with you, most important is to know what to expect. Managing all multiparts types would make the component very complex I believe, for little added-value.

...

When there are several calls to addContent(...) for the same content

type,

...

is provided text appended to content already present in existing part ? Ie, in sample above, I would get an email with a plain/text part containing "text1text2" and an html part with "text3" ? If text/plain parts are added instead of concatenated, then in sample below, it would mean that "text2" would obliterate "text1" added before, as it will maybe never be displayed by the client (depending on how the client interprets this case).

Another thing, when you add html content to an email, it's usually for its better formatting features compared to plain text. A common use-case (for example, if you want to send a newsletter), is to include some images in the html page sent. To do that, you can't just provide the html content, then some attached images. Doing that you can only send an html page (without inline images) and images attached. To send an html document with inline image, you need to send a multipart/related, instead of a "text/html" part, and generate content-ids for each image/attachment. Is it managed by the mail sender ?

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 !

No pb, even if I'm not an email expert in any way ;-) But I think I will use your component as client when I'll implement the reply feature in Mail Archive app, at that time it will be easier to challenge it against my own use-cases. What I just saw very quickly: - I wonder if DefaultMailSenderUtils#getDocumentRef(String docName) is not the same as DocumentReferenceResolver#resolve() ? - from MimePartCreator#createAttachmentPart(), you create a temporary file in order to create the MimeBodyPart, maybe you could use a BufferedDataSource to avoid that ? - from MimePartCreator#createHtmlPart(), you use a pattern to find inline-d attachments ("cid:") : src=('|\")cid:([^'\"]*)('|\") ...but in HTML nothing prevents from having "src = 'cid:...'" (with white spaces), that would not be match by that pattern. Also, I'm not sure I understand well, but it seems to consider that file name is what is in the "cid:*" value, but it's usually not the case (usually, content-id is a unique id built from filename, both values being provided as Content-Id and filename headers). - you call MimePartCreator#createAttachmentPart() for both types of attachments ("embedded images", and all other attachments), but "INLINE_DISPOSITION" is used as disposition for all of them. I think non-embedded attachments should have a disposition of ATTACHMENT. It's not so important though as anyway clients do whatever they like with your attachments. - currently it seems not to manage possibility to send a mail with a "Sender:" different than "From:" header. It is sometimes useful, for example in mailing-lists, usually "From:" is the human person who is sending the mail, and "Sender:" is the mailing-list server that effectively sends it to mailing-list recipients. For SMTP servers that allow that, it is then possible to send mails from a unique account (the sender) "on behalf of" the real users (in from/to), if it has the rights to do so of course.

...

By the way it would be quite nice, to be able to round-trip between an XWiki page content (html) and a multipart/related part. I wonder how it is managed by Newsletter Application...

Using mail Templates enables you to include some Wiki content in it. Perhaps it is what the Newsletter application uses ?

Cheers, Thomas

...

Note: concerning the "mail parser" implemented in Mail Archive app, currently, it does not differentiate multipart/related, multipart/alternative and multipart/mixed. The same process applies: all "text/html" parts are parsed into a unique concatenated html content, all "text/plain" parts are parsed into a unique concatenated pure text

content.

...

If some attachments have content-ids, their reference are replaced in the html content by a link to proper attached file. This almost respects RFC1341, in that it almost considers all multiparts as "mixed" (but not in sequence, as text and html are grouped together). The resulting display is fine in 99,99% of cases, as far as I tested.

BR, Jeremie

...

2013/1/7 Thomas Mortagne <[email protected]>

...

On Mon, Jan 7, 2013 at 12:12 AM, Vincent Massol <[email protected]> wrote:

...

On Jan 6, 2013, at 10:54 PM, Thomas Delafosse <

[email protected]> wrote:

...

...

The advantage of jSoup is that it handles the problems I could have

if

...

...

the

...

...

html part is not well written,

Actually this is exactly what the XWiki HTML parser does too :)

I really think you should use our parser.

Plus de HTML parser is very important so the more we test it the better.

...

Thanks -Vincent

...

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 <

[email protected]

...

...

wrote:

...

Le 2 janv. 2013 18:44, "Thomas Delafosse" < [email protected]> a écrit : > > On Fri, Dec 28, 2012 at 9:01 PM, Sergiu Dumitriu < [email protected]> wrote: > >> On 12/26/2012 10:18 AM, Vincent Massol wrote: >>> >>> On Dec 26, 2012, at 4:01 PM, Thomas Delafosse < >> [email protected]> wrote: >>> >>>> On Wed, Dec 26, 2012 at 3:23 PM, Vincent Massol < [email protected] > >> wrote: >>>> >>>>> >>>>> On Dec 26, 2012, at 3:15 PM, Thomas Delafosse < >> [email protected]> >>>>> wrote: >>>>> >>>>>> 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.ht...

...

...

...

...

...

>> >> 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne _______________________________________________ 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