You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2003/06/30 18:54:12 UTC
Deprecate Mail.getSender/setSender
I propose that we deprecate Mail.getSender/setSender in favor of unambiguous
names that relate to the SMTP RFC: Mail.getReversePath/setReversePath.
As it stands, we have:
Mail.get/setSender === mail.smtp.from === reverse-path
Mail.get/setSender !== Message.get/setSender
Danny has often had to remind people of that last point. If we don't fix
the terminology now, it is only going to become worse when we start making
use of VERP.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Deprecate Mail.getSender/setSender
Posted by Danny Angus <da...@apache.org>.
hurried or impetuous NOT irascible!
> Sometimes it is difficult to
> follow the subtleties of a foreign language.
Sorry.
d.
RE: Deprecate Mail.getSender/setSender
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
Danny,
If by hasty you mean hurried or impetuous, I agree; if you mean irascible, I didn't intend to :-) . Sometimes it is difficult to follow the subtleties of a foreign language.
Vincenzo
> -----Original Message-----
> From: Danny Angus [mailto:danny@apache.org]
> Sent: martedi 1 luglio 2003 9.32
> To: James Developers List
> Subject: RE: Deprecate Mail.getSender/setSender
>
>
> You can't change the Mailet API in v2 without releasing it as
> another version.
> Make this change in v3.
> FWIW it hasn't been seen as a big problem before now, I don't see
> the need to be hasty.
>
> d.
>
>
> > -----Original Message-----
> > From: Vincenzo Gianferrari Pini
> > [mailto:vincenzo.gianferraripini@praxis.it]
> > Sent: 01 July 2003 07:54
> > To: James Developers List
> > Subject: RE: Deprecate Mail.getSender/setSender
> >
> >
> > There are 53 getSender() strings in v2:
> > 43 in matchers/mailets
> > 24 in the AbstractRedirect hierarchy
> > 19 in other matchers/mailets
> > 10 in 4 modules.
> >
> > There are 6 setSender(...) strings in v2:
> > 3 in matchers/mailets
> > 3 in the AbstractRedirect hierarchy
> > 0 in other matchers/mailets
> > 3 in 1 module.
> >
> > As this point comes from discussions over the AbstractRedirect
> > hierarchy classes, that I'm for now modifying, I would easily
> > change it there in one shot, but I think that it would be very
> > cumbersome to continue to keep by hand the sources different in
> > v3 from v2 just for this in 27 points.
> >
> > And in general, the effort of a one shot overall change is
> > minimal, while to maintain the two versions different on an
> > ongoing basis is IMHO much higher.
> >
> > Secondly, we could insert the new
> > Mail.getReversePath/setReversePath methods in both versions and
> > deprecate Mail.getSender/setSender only in v3 for now (to avoid
> > too many deprecation warnings in third party mailets).
> >
> > So for me it's +1 if we change it in both versions (with or
> > without a v2 deprecation), but -0 if we keep it different.
> >
> > Vincenzo
> >
> > > -----Original Message-----
> > > From: Serge Knystautas [mailto:sergek@lokitech.com]
> > > Sent: martedi 1 luglio 2003 3.36
> > > To: James Developers List
> > > Subject: Re: Deprecate Mail.getSender/setSender
> > >
> > >
> > > Noel J. Bergman wrote:
> > > > I propose that we deprecate Mail.getSender/setSender in favor
> > > of unambiguous
> > > > names that relate to the SMTP RFC:
> Mail.getReversePath/setReversePath.
> > >
> > > Works for me. +1. This would likely need to be applied only
> > to the 3.0
> > > branch though.
> > >
> > > --
> > > Serge Knystautas
> > > President
> > > Lokitech >>> software . strategy . design >> http://www.lokitech.com
> > > p. 301.656.5501
> > > e. sergek@lokitech.com
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: james-dev-help@jakarta.apache.org
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: james-dev-help@jakarta.apache.org
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Deprecate Mail.getSender/setSender
Posted by Danny Angus <da...@apache.org>.
You can't change the Mailet API in v2 without releasing it as another version.
Make this change in v3.
FWIW it hasn't been seen as a big problem before now, I don't see the need to be hasty.
d.
> -----Original Message-----
> From: Vincenzo Gianferrari Pini
> [mailto:vincenzo.gianferraripini@praxis.it]
> Sent: 01 July 2003 07:54
> To: James Developers List
> Subject: RE: Deprecate Mail.getSender/setSender
>
>
> There are 53 getSender() strings in v2:
> 43 in matchers/mailets
> 24 in the AbstractRedirect hierarchy
> 19 in other matchers/mailets
> 10 in 4 modules.
>
> There are 6 setSender(...) strings in v2:
> 3 in matchers/mailets
> 3 in the AbstractRedirect hierarchy
> 0 in other matchers/mailets
> 3 in 1 module.
>
> As this point comes from discussions over the AbstractRedirect
> hierarchy classes, that I'm for now modifying, I would easily
> change it there in one shot, but I think that it would be very
> cumbersome to continue to keep by hand the sources different in
> v3 from v2 just for this in 27 points.
>
> And in general, the effort of a one shot overall change is
> minimal, while to maintain the two versions different on an
> ongoing basis is IMHO much higher.
>
> Secondly, we could insert the new
> Mail.getReversePath/setReversePath methods in both versions and
> deprecate Mail.getSender/setSender only in v3 for now (to avoid
> too many deprecation warnings in third party mailets).
>
> So for me it's +1 if we change it in both versions (with or
> without a v2 deprecation), but -0 if we keep it different.
>
> Vincenzo
>
> > -----Original Message-----
> > From: Serge Knystautas [mailto:sergek@lokitech.com]
> > Sent: martedi 1 luglio 2003 3.36
> > To: James Developers List
> > Subject: Re: Deprecate Mail.getSender/setSender
> >
> >
> > Noel J. Bergman wrote:
> > > I propose that we deprecate Mail.getSender/setSender in favor
> > of unambiguous
> > > names that relate to the SMTP RFC: Mail.getReversePath/setReversePath.
> >
> > Works for me. +1. This would likely need to be applied only
> to the 3.0
> > branch though.
> >
> > --
> > Serge Knystautas
> > President
> > Lokitech >>> software . strategy . design >> http://www.lokitech.com
> > p. 301.656.5501
> > e. sergek@lokitech.com
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: james-dev-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
RE: Deprecate Mail.getSender/setSender
Posted by Vincenzo Gianferrari Pini <vi...@praxis.it>.
There are 53 getSender() strings in v2:
43 in matchers/mailets
24 in the AbstractRedirect hierarchy
19 in other matchers/mailets
10 in 4 modules.
There are 6 setSender(...) strings in v2:
3 in matchers/mailets
3 in the AbstractRedirect hierarchy
0 in other matchers/mailets
3 in 1 module.
As this point comes from discussions over the AbstractRedirect hierarchy classes, that I'm for now modifying, I would easily change it there in one shot, but I think that it would be very cumbersome to continue to keep by hand the sources different in v3 from v2 just for this in 27 points.
And in general, the effort of a one shot overall change is minimal, while to maintain the two versions different on an ongoing basis is IMHO much higher.
Secondly, we could insert the new Mail.getReversePath/setReversePath methods in both versions and deprecate Mail.getSender/setSender only in v3 for now (to avoid too many deprecation warnings in third party mailets).
So for me it's +1 if we change it in both versions (with or without a v2 deprecation), but -0 if we keep it different.
Vincenzo
> -----Original Message-----
> From: Serge Knystautas [mailto:sergek@lokitech.com]
> Sent: martedi 1 luglio 2003 3.36
> To: James Developers List
> Subject: Re: Deprecate Mail.getSender/setSender
>
>
> Noel J. Bergman wrote:
> > I propose that we deprecate Mail.getSender/setSender in favor
> of unambiguous
> > names that relate to the SMTP RFC: Mail.getReversePath/setReversePath.
>
> Works for me. +1. This would likely need to be applied only to the 3.0
> branch though.
>
> --
> Serge Knystautas
> President
> Lokitech >>> software . strategy . design >> http://www.lokitech.com
> p. 301.656.5501
> e. sergek@lokitech.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Deprecate Mail.getSender/setSender
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> I propose that we deprecate Mail.getSender/setSender in favor of unambiguous
> names that relate to the SMTP RFC: Mail.getReversePath/setReversePath.
Works for me. +1. This would likely need to be applied only to the 3.0
branch though.
--
Serge Knystautas
President
Lokitech >>> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Deprecate Mail.getSender/setSender
Posted by Steve Brewin <sb...@synsys.com>.
What, name methods after what they do? Where's the challenge in that?
+1
-- Steve
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 30 June 2003 17:54
> To: James-Dev Mailing List
> Subject: Deprecate Mail.getSender/setSender
>
>
> I propose that we deprecate Mail.getSender/setSender in favor
> of unambiguous
> names that relate to the SMTP RFC: Mail.getReversePath/setReversePath.
>
> As it stands, we have:
>
> Mail.get/setSender === mail.smtp.from === reverse-path
> Mail.get/setSender !== Message.get/setSender
>
> Danny has often had to remind people of that last point. If
> we don't fix
> the terminology now, it is only going to become worse when we
> start making
> use of VERP.
>
> --- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Deprecate Mail.getSender/setSender
Posted by Danny Angus <da...@apache.org>.
If there were a vote I'd happily be +1, no contest IMO.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 30 June 2003 17:54
> To: James-Dev Mailing List
> Subject: Deprecate Mail.getSender/setSender
>
>
> I propose that we deprecate Mail.getSender/setSender in favor of
> unambiguous
> names that relate to the SMTP RFC: Mail.getReversePath/setReversePath.
>
> As it stands, we have:
>
> Mail.get/setSender === mail.smtp.from === reverse-path
> Mail.get/setSender !== Message.get/setSender
>
> Danny has often had to remind people of that last point. If we don't fix
> the terminology now, it is only going to become worse when we start making
> use of VERP.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>