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