You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mailet-api@james.apache.org by Steve Brewin <sb...@synsys.com> on 2011/12/19 11:02:21 UTC
Fwd: Re: [mailets] Proposal: MailetContext enhancement
Discussion moved over from James Dev as per Stefano's suggestion.
-------- Original Message --------
Subject: Re: [mailets] Proposal: MailetContext enhancement
Date: Sun, 18 Dec 2011 21:04:10 +0100
From: Stefano Bagnara <ap...@bago.org>
Reply-To: James Developers List <se...@james.apache.org>
To: James Developers List <se...@james.apache.org>
2011/12/18 Steve Brewin<sb...@synsys.com>:
> Hi
>
> To decouple org.apache.james.transport mailets from
> org.apache.james.core.MailImpl the following methods need to be added to
> org.apache.mailet.Mail:
>
> setRemoteAddr(String);
>
> setRemoteHost(String);
>
> setSender(MailAddress);
>
> Nothing wrong with this in my view. They probably should have been there all
> along!
What about adding these two?
- Mail createMail(MailAddress sender) => sets remoteaddr/host to the
local james address
- Mail cloneMail(Mail orig, MailAddress sender) => copies remoteaddr/host
I don't like to add too many public methods if they are not needed.
For what I remember the 2 methods above satisfy the current use case
BTW this is a mailet issue and we should move to the mailet ml and to
mailet-api JIRA, so that other interested parties (if any) can add
their opinion.
Here is an old proposal I just found:
https://issues.apache.org/jira/browse/MAILET-31
Stefano
> The Mailets coupled to MailImpl are:
>
> AbstractRecipientRewriteTable
>
> AbstractRedirect
>
> DSNBounce
>
> Each uses new MailImpl(Mail) to create a new instance of Mail. This would
> change to getMailetContext().createMail(Mail).
>
> If we are to update MailetContext, which will require a new version of
> Mailet API, we should make the changes to Mail in the same version.
>
> Opinions?
>
> Cheers
> --Steve
>
> On 18/12/2011 11:45, Steve Brewin wrote:
>>
>> Missed...
>>
>> createMail(Mail mail, Mail.State state)
>>
>> ...to satisfy the a need to create a copy of a Mail. I'll review the needs
>> of the org.apache.james.transport.mailets to make sure we haven't missed
>> anything else!
>>
>> Cheers
>> --Steve
>>
>>
>> On 18/12/2011 10:25, Norman Maurer wrote:
>>>
>>> Yeah I think the latter makes most sense.
>>>
>>> Bye
>>> Norman
>>>
>>> 2011/12/18, Steve Brewin<sb...@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<sb...@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<sb...@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<se...@james.apache.org>
>>>>>>>> For additional commands, e-mail:
>>>>>>>> server-dev-help@james.apache.****org<
>>>>>>>>
>>>>>>>> server-dev-help@james.**apache.org<se...@james.apache.org>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> ------------------------------**------------------------------**---------
>>>>>> To unsubscribe, e-mail:
>>>>>>
>>>>>> server-dev-unsubscribe@james.**apache.org<se...@james.apache.org>
>>>>>> For additional commands, e-mail:
>>>>>> server-dev-help@james.apache.**org<se...@james.apache.org>
>>>>>>
>>>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
- - - - - - - - - - - - - - - - - -
This private and confidential e-mail has been sent to you by Synergy Systems Limited. It may not represent the views of Synergy Systems Limited.
If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with "received in error" as the subject and then delete it from your mailbox.