> > I'm fine with reving the version to Mailet API v2.something or some
other
> > procedural change. That's similar to why we've proposed calling the
next
> > version 2.2.0, instead of 2.1.4.
> I think this is the first revision to the mailet API (aside from v3
> changes) since its release many years ago. And as it's minor, I would
> move it to 1.1 as opposed to using the Microsoft versioning formula
LOL We weren't. I had initially called it Mailet API v2 last year, and
Danny corrected me that we were already using Mailet API v2, so the new one
became Mailet API v3.
FWIW, prior to Danny introducing Soren's changes into Mailet API v3 (MAIN),
these were the only interface changes in the current CVS:
revision 1.2
date: 2001/08/06 03:37:21; author: serge; state: Exp; lines: +0 -9
Removed the setMessage(InputStream) message since it is not used in the
server and is better handled by creating a MimeMessage and setting that.
revision 1.5.4.3
date: 2003/05/28 20:26:07; author: noel; state: Exp; lines: +11 -0
Added void sendMail(Mail) to MailetContext
Even going back to the Sept 2000 James v1.2 refactoring, the Mailet API was
still amazingly stable. The biggest changes were made to MailetContext.
There were some changes then that could be used to suggest that Mailet API
v1 was related to James v1.2, but that's ancient history.
In any event, as Danny says, I think that Mailet API v2 for the present one
seems to be well established, even if debatably correct.
FWIW, even though it would not show up in the method signature, there is an
old issue of "[Matcher] does not support concept of Collection of Collection
of MailAddress for recipients... hopefully in the next release)."
I agree that the Mailet API has been, and must be kept, stable and
considered. I am amazed at how little it has changed, and I don't consider
that a bad thing at all. :-) I think that we're all agreed that it would
be quite bad to introduce anything into a stable branch that we are not
committed to supporting for the long term. We've already agreed, for
example, that the experimental changes for datasource handling may not
survive to release.
As important are the storage formats. We must be able to handle old data,
and we should do our best to have bidirectional data compatibility.
More on the other aspects of the discussion in a bit.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
