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 08:52:09 GMT
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>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message