S�ren Hilmer wrote:
> On Wednesday 05 November 2003 16:33, Noel J. Bergman wrote:
> > We have to support what we release as a public interface.
> > In some cases, the code as it exists may not be what we
> > want to support, and that is another reason for why it
> > isn't exposed.
> I can see your point on what we expose we need to support.
> But IMO people messing at this level needs to have a certain level of
> competance anyway, eg. they need to have understood the inner workings
> of the mailet/matcher they are extending. This initiative is just to
> lend those developers a helping hand.
Exposing internals, as opposed to behavior, is not necessarily giving anyone
a helping hand. I'm just saying to be careful, not rather than do this by
rote. Considering that this is Open Source, I would rather have someone
come to us and point out where we should expose something, than expose too
much and be backed into a corner when it comes to changing how something
internal is implemented.
> I agree that Andreas's DSN solution should make it into
> the next build. My only concern is that we get yet
> another processor with special meaning, besides root and
> error. I suggest that we make the processor name a
> parameter to RemoteDelivery.
> <DSNProcessor>dsn</DSNProcessor>
I absolutely agree. Isnt' that what we've been discussing? I'm almost
certain that I mentioned that in one of my e-mails.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
