james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <norman.mau...@googlemail.com>
Subject Re: [mailets] Proposal: MailetContext enhancement
Date Sun, 18 Dec 2011 10:25:20 GMT
Yeah I think the latter makes most sense.

Bye
Norman

2011/12/18, Steve Brewin <sbrewin@synsys.com>:
> Hi Norman
>
> Well I was trying to be less radical, but a createMail() method or
> methods as a replacement for the sendMail() ones is a better solution.
>
> If we were to have just a single create method, it would be:
>
> createMail(MimeMessage message, Mail.State state)
>
> Note that I have changed 'state' from a simple String to an enum.
>
> As the API deals in things like MailAddress, it is perhaps reasonable to
> add:
>
> createMail(MailAddress sender, Collection<MailAddress>  recipients,
> MimeMessage message, Mail.State state)
>
> The other variants are just helper methods that should not be forced on
> an API. They could be implemented in Mailet Base if someone cared to do
> so, as could the old sendMail() methods.
>
> Cheers
> --Steve
>
> On 18/12/2011 08:52, Norman Maurer wrote:
>> Hi Steve,
>>
>> I think it would make more sense to add a method to the MailetContext to
>> create a new Mail object, so we could also make some other mailets that
>> are
>> currently using MailImpl directly independent of James Server.
>>
>> So I'm in favor to add such a method and @deprecate all the sendMail(..)
>> methods except the one the take a Mail object as parameter.
>>
>> WDYT ?
>>
>> Norman
>>
>>
>> 2011/12/17 Steve Brewin<sbrewin@synsys.com>
>>
>>> For a new Mail, using MailetContext.sendMail(Mail mail) requires that the
>>> mailet knows how to create an implementation of Mail that is specific to
>>> the server hosting the Mailets. This breaks Mailet portability, which is
>>> why the other sendMail() methods exist.
>>>
>>> MailetContext.sendMail(Mail mail)  exists to resend an existing Mail, the
>>> others are for creating and sending new Mails.
>>>
>>> --Steve
>>>
>>>
>>> On 17/12/2011 19:53, Norman Maurer wrote:
>>>
>>>> I wonder why you can not use :
>>>>
>>>> MailetContext.sendMail(Mail mail)
>>>>
>>>> Can you give some more details ?
>>>>
>>>> Bye,
>>>> Norman
>>>>
>>>> 2011/12/17 Steve Brewin<sbrewin@synsys.com>
>>>>
>>>>   Hi
>>>>> Interface org.apache.mailet.****MailetContext defines four sendMail()
>>>>>
>>>>> methods that construct and send an org.apache.mailet.Mail instance.
>>>>> None
>>>>> of
>>>>> these methods provide the ability to specify the mail attributes that
>>>>> should be attached.
>>>>>
>>>>> I propose adding a further four methods mirroring the existing ones
>>>>> each
>>>>> with an extra parameter:
>>>>>
>>>>> @param attributes
>>>>>         The Mail attributes to attach
>>>>>
>>>>> This functionality is generally useful. The lack of it is a blocker to
>>>>> some SieveMailboxMailet enhancements.
>>>>>
>>>>> Q1: Are there any objections to this?
>>>>>
>>>>> Q2: The release version of the Mailet API is 2.4, so logically we
>>>>> should
>>>>> step to 2.5. There is already a 2.5 version in trunk containing a few
>>>>> changes. We can:
>>>>>
>>>>> a) Combine the existing changes with these proposed changes
>>>>> b) Park the existing changes and make 2.5 = 2.4 plus these proposed
>>>>> changes
>>>>> c) Something else?
>>>>>
>>>>> Opinions please.
>>>>>
>>>>> Q3: Whatever we decide to do for Q2, for JSieve development to proceed
>>>>> this version of the Mailet API needs to be implemented by
>>>>> JamesMailetContext in James Server trunk. Are there any objections to
>>>>> this?
>>>>>
>>>>> Cheers
>>>>> --Steve
>>>>>
>>>>>
>>>>> ------------------------------****----------------------------**
>>>>> --**---------
>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.****apache.org<
>>>>> server-dev-**unsubscribe@james.apache.org<server-dev-unsubscribe@james.apache.org>
>>>>> For additional commands, e-mail: server-dev-help@james.apache.****org<
>>>>> server-dev-help@james.**apache.org<server-dev-help@james.apache.org>>
>>>>>
>>>>>
>>>>>
>>> ------------------------------**------------------------------**---------
>>> To unsubscribe, e-mail:
>>> server-dev-unsubscribe@james.**apache.org<server-dev-unsubscribe@james.apache.org>
>>> For additional commands, e-mail:
>>> server-dev-help@james.apache.**org<server-dev-help@james.apache.org>
>>>
>>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message