Serge Knystautas wrote:
>
> ----- Original Message -----
> From: "Charles Benett" <[EMAIL PROTECTED]>
> > 1) Can we change MailRepository (and hence the file and db
> > implementations) to use mailet.Mail not james.core.MailImpl? I can't see
> > any obvious need to use a specific class rather than a type.
>
> I view MailRepository as something JAMES provides and that is not part of
> the mailet API. Also, the MailRepository needs complete access to all
> getter and setter methods of the implementation class... otherwise how can
> the repository store and reinstantiate these objects?\
I'm OK with the getters, but why does it need the setters? Why not just
call an appropriate constructor?
>
> > 2) Someone (Serge, I think) has noted in mailet.Mail that there are
> > several methods which don't really belong there: clear(); setSender(),
> > setRecipients(), setRemoteHost(), setRemoteAddress(). I agree they
> > shouldn't be here. To these I would add: setName() and setMessage(). I
> > thought the point of the Mailet API was for mail processing, in which
> > case users of the Mailet API shouldn't need/ be able to create messages
> > (they can duplicate them). Creating messages (ie within the mailserver)
> > is handled by the SMTP server (or an IMAP for drafts). These methods
> > belong in an implementation specific interface, something like
> > RecyclableMail. But I don't think we recycle Mail objects, so they are
> > unnecessary.
>
> These aren't there for object recycling. I'm not as sure about the setName
> method, but I know the setMessage is useful if your mailet is making
> significant changes to the MimeMessage object. I could see some trouble
> with setName getting called (maybe we'll lose a reference to the object in
> the mail repository... not really sure if this is a problem). I've gone
> back and forth numerous times over whether you should be able to send a
> message... I'm still not completely swayed either way.
>
> That said, I'll have to review the mailets to see which might be using these
> methods.
If there are good reasons to keep them, that's fine. But what about:
clear(); setSender(), setRecipients(), setRemoteHost(),
setRemoteAddress()?
Charles
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives: <http://www.mail-archive.com/james%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
