Missing Mailet APIs related to attributes?

["Noel J. Bergman" <no...@devtech.com>]

Seems to me that we either need to add:

  sendMail(Sender, Recipients, Message, State, Attributes);
  sendMail(Sender, Recipients, Message, Attributes);

or make it easier for developers to create a new Mail instance, which pretty
much means the same sort of parameters, since Sender and Recipients are
read-only properties.

Meanwhile, we can create a MailImpl when we need them.

	--- Noel


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

RE: Missing Mailet APIs related to attributes?

["Noel J. Bergman" <no...@devtech.com>]

Serge Knystautas wrote:
> Danny Angus wrote:
> > Serge Knystautas wrote:
> > > Noel J. Bergman wrote:
> > > > Seems to me that we either need to add:
> > > >
> > > >  sendMail(Sender, Recipients, Message, State, Attributes);
> > > >  sendMail(Sender, Recipients, Message, Attributes);
> > > >
> > > > or make it easier for developers to create a new Mail instance,
> > > > which pretty much means the same sort of parameters, since
> > > > Sender and Recipients are read-only properties.
> > >
> > > I don't like the idea of exposing MailImpl, and it seems we're
> > > already cheating in this regard.  I would prefer deprecating
> > > all existing sendMail() methods and instead do:
> > >
> > > public interface MailetContext {
> > >   Mail newMail();
> > >   void queue(Mail mail);
> >
> > +1
> > Although I favour spoolMail(...) as a name
>
> spool(Mail) would work for me

Uh, guys.  We do have a method, which I seem to recall we've talked abut
renaming, for spooling a Mail instance.  That isn't the issue.  Constructing
a Mail object is what we can't do today, and Mail newMail() won't work
without other changes.

As I said, there are methods on MailImpl that aren't accessible in the
Mailet API.  Specifically, the methods for managing the envelope aren't
exposed.  We can change recipients though getRecipients, but not the
envelope sender (we've talked about changing that method name before
exposing it).  Perhaps we should expose those mutators, and then do
something with a wrapper class that prevents changing the envelope when
there is a reason for making that information read-only.  That would mean
declaring an exception in the interface.

This is a Mailet API change, not for James v2.x.

	--- Noel


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

Re: Missing Mailet APIs related to attributes?

[Serge Knystautas <se...@lokitech.com>]

Noel J. Bergman wrote:
> Seems to me that we either need to add:
> 
>   sendMail(Sender, Recipients, Message, State, Attributes);
>   sendMail(Sender, Recipients, Message, Attributes);
> 
> or make it easier for developers to create a new Mail instance, which pretty
> much means the same sort of parameters, since Sender and Recipients are
> read-only properties.
> 
> Meanwhile, we can create a MailImpl when we need them.

I don't like the idea of exposing MailImpl, and it seems we're already 
cheating in this regard.  I would prefer deprecating all existing 
sendMail() methods and instead do:

public interface MailetContext {
   Mail newMail();
   void queue(Mail mail);
   ..
   ..
}

I'm not wedded to the two names.  I like queue(Mail) over send(Mail) 
because send() implies a) it's going some place else and b) does not 
address how message could be placed in other states (like spam, error, 
whatever).

-- 
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com

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