20 Dec
2012
20 Dec
'12
3:44 p.m.
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 <
jeremie.bousquet(a)gmail.com> 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 <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
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