james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject Mailet API changes
Date Tue, 15 Jul 2003 14:46:36 GMT
Danny,

Amusingly, you replied to his commit message for the main branch, but that
doesn't change the thrust of your argument, since he also committed to the
v2 branch.  :-)

Is there is change that you would want to make to the proposed API, or are
you raising a procedural issue?  I would like to see the functionality
integrated.

Let's talk about this.  I agree that we want the API to be stable, but we
had talked about putting this feature into v2.  That has been mentioned
multiple times on the lists, and listed on the v2 Plans page
(http://nagoya.apache.org/wiki/apachewiki.cgi?JamesV2/Plans).  Now that
Vincenzo has kindly made the change, we've obviously come to a point where
we have to make a decision rather than deal with lazy consensus.

There are two changes to the Mailet API that have been proposed for v2.2
that are compatible:

  1 - mail attributes
  2 - deprecating setSender/getSender in favor
      of setReversePath/getReversePath

Neither of those changes breaks existing code, unlike the incompatible ones
made so far for v3.

IMO, deprecating setSender/getSender ought to be done.  It isn't as if
building James v2 doesn't already involve deprecated methods from Avalon.
And in our case, we would do it properly, which means we document the new
calls, and we keep the old ones.  If we know that we will be deprecating a
method, I think that we should do it.  Deprecation is about advanced warning
and better practice.

As for Mail Attributes, I also think that we should do them.  The change
doesn't break any existing code, is necessary to address some commonly
requested features, and the coding changes were specifically engineered to
be compatible with existing stores.  Yes, we should review the changes to
make sure that the specific API is what we want to carry forward.  I would
compare what we've done with the Servlet API, as a comparison.

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.

	--- Noel

-----Original Message-----
From: Danny Angus [mailto:danny@apache.org]
Sent: Tuesday, July 15, 2003 9:23
To: James Developers List
Subject: RE: cvs commit: james-server/src/java/org/apache/mailet
Mail.java


Vincenzo,

I think you should remove this, it changes the Mailet API, the API should
not change between versions in this way. It is important for published API's
to remain static and for changes to be well publicised and stable before any
release is made. Making a change in this way may not be directly harmful but
it does violate good practice.

The existing plan is for this to be available in Mailet v3, not to be
retro-fitted to v2.

I think there might be a case for proposing an interim Mailet v2.1 which
includes this and some other forthcoming features of v3, but I don't think
that this is a good way of doing it.

d.


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


Mime
View raw message