> > I don't know about processor. I think we ought to go back and look at a
> > processor being a mailet.
> Doesn't really change things, fwiw I'm agnostic about this now, and Serge
> for one has the opposite opinion to you.
I think it is worth considering, but I'm not sure on which side it will fall
out. We'll have to look closely at the interfaces, particularly
configuration, which could be very different it we follow through with what
you're saying below. The obvious common method is the basic service(Mail)
method.
> I'm proposing removing everything from the API which *can* be done by
JNDI,
> including configuration and most if not all of mailet context.
I think that might be overkill for the simple things, but see below. I do
believe that we could use JNDI as the sole implementation used to provide
the configuration information.
> (but in a way that a few find/replace session could upgrade much of
> peoples own code)
Generic[Mailet|Mailet] could continue to provide the current interface by
wrapping the JNDI context.
> [dynamic reconfiguration] could be done quite easily if we can settle on
> the trigger event or condition
Agreed.
> > The original code added All and Null to the end. We replaced that
> > with explicit classes so that you would know that it had fallen off.
> Hmm.. Ok but that doesn't change the fact that I'd like to remove it.
:)
> adding processor to the API would allow different implementations to
> behave differently, so I can live with this the way it is.
What value do you see to adding Processor to the Mailet API? Forget the
question of whether Processor extends Mailet or not. What additional
interface(s) are you trying to provide to matchers and mailets?
> Note that I wouldn't want this (existing) behaviour to be part of the
> contract of Processor, just the implemented behaviour of LinearProcessor.
Agreed.
We can add a class attribute to the <processor> element (even if a processor
is a Mailet, there are still configuration issues that make it a special
kind, e.g., it is addressable), and processor implementations can provide
different default and/or explicit behavior.
> to my mind we do not support virtual hosting in the way that most people
> understand it.
Please define what you feel is missing. The two things I've heard said are
that:
(a) people want to be able to use [EMAIL PROTECTED] as a valid POP3 name
(b) we don't have a means to partition admin privileges per domain
In the case of (a)m I think we need to do a much better job of educating
people about virtual user tables, and (b) will be tied to our JNDI work,
amongst other things. I'll also agree with respect to (a) that our
primitive management tools should be more helpful, rather than requiring the
population to be done by hand.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
