Re: [xwiki-devs] Future of mailsender plugin

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 <thomas.mortagne(a)xwiki.com>