> > > > As you already said, Redirect suffers from the need of backward > compatibility, > > > that we must guarantee. We could in the future create a new > mailet, with > a > > > different name (which name BTW?) following more consistently the > conventions. > > > This mailet has become a veritable swiss-army knife of confusion. :) > > Always was. I propose that for undocumented defaults, that we change them > to be consistent (as discussed in this thread), and document the changes. > Doing: > > <mailet match="All" class="Redirect"/> > > should effectively do nothing because you haven't told it what to change. > We can't do that. It would break most config.xml files around. Anyhow, I'm documenting everything right now.
I suggest to complete what I'm doing getting a totally back compatible and documented Redirect, and later on we can have a new one, called "TheThing" (I'm joking :-), simply no name comes to my mind) that behaves as Noel says, and Redirect extends it just changing the defaults to keep the compatibility. > > It might benefit by having some mailets that extend this with options > > hardset and a more understandable name. > > Forward, for example. :-) By default, Forward requires nothing > more than a > recipient list, and should normally do nothing but change it. The Notify > and Bounce mailets are also pretty clean. > > The one parameter whose default isn't related to "change/don't change" is > <passthrough>. AbstractRedirect defaults it to false. AbstractNotify > changes that so that Notify/Bounce mailets leave the original > message in the > spool by default. That behavior seems fine, so long as it is documented. Doing that too. Vincenzo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
