20 Dec
2012
20 Dec
'12
3:48 p.m.
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 <jeremie.bousquet(a)gmail.com>
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 <vincent(a)massol.net>
cc,
https://github.com/xwiki-contrib/xwiki-application-mailarchive/tree/master/…
rewriting
a
change
https://github.com/xwiki-contrib/xwiki-application-mailarchive/blob/master/…
https://github.com/xwiki-contrib/xwiki-application-mailarchive/blob/master/…
_______________________________________________
devs mailing list
devs(a)xwiki.org
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
On Dec 20, 2012, at 1:35 PM, Thomas Mortagne <thomas.mortagne(a)xwiki.com>
wrote:
cc,
On Thu, Dec 20, 2012 at 12:55 PM, Thomas
Delafosse <
thomas.delafosse(a)xwiki.com> 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 >> 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 >
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
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 <ludovic(a)xwiki.com>
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 >>> 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 >> the
>>> content type of the emails from these APIs
>>>
>>> Ludovic
>>>
>>>
>>>
>>>
>>>
>>> 2012/11/23 Jeremie BOUSQUET <jeremie.bousquet(a)gmail.com>
>>>
>>>> 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):
>>>
>>>
>>
>
>>> What's available from parsed mail body is:
>>>
>>>
>>
>
>>>>
>>>> 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 <ludovic(a)xwiki.com>
>>>>
>>>>> 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs