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/xwiki-contrib-mailsince > > > 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/xwiki-contrib-mail/src/main/java/org/xwiki/contrib/mail/IMailComponent.java > > >>>> What's available from parsed mail body is: > > >>>> > > >>>> > > >>> > > >> > > > https://github.com/xwiki-contrib/xwiki-application-mailarchive/blob/master/xwiki-contrib-mail/src/main/java/org/xwiki/contrib/mail/MailContent.java > > >>>> > > >>>> 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
