> 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.
>My specific point about order is that there are things that we might add
to
>the API that might be done, instead, by pluggable services that are
accessed
>via JNDI.
I'm proposing removing everything from the API which *can* be done by JNDI,
including configuration and most if not all of mailet context. (but in a
way that a few find/replace session could upgrade much of peoples own code)
> I would also like to see dynamic reconfiguration.
Yeah that could be done quite easily if we can settle on the trigger event
or condition
> As I've said to you before, that was NOT a change that Peter put in. We
> simply changed how it was done. 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.
OTOH adding processor to the API would allow different implementations to
behave differently, so I can live with this the way it is.
Note that I wouldn't want this (existing) behaviour to be part of the
contract of Processor, just the implemented behaviour of LinearProcessor.
>I would be happy to see several new attributes added, as we did
>on[*]Exception. I had wanted to add a class attribute, but that might not
>be necessary (not if we do end up switching back to Mailets as
processors),
>and could agree with requiring an explicit end clause for processing.
>Again, this whole area might change depending on the mailet as processor
>approach.
Agree. We can thrash this all out in the time honoured fasion!
>I am not sure that it has been outstanding. A lot of people who ask for
>virtual hosting don't realize that we already have it, or think that they
>want something else.
We'll have to agree to differ then, because to my mind we do not support
virtual hosting in the way that most people understand it.
What we do do is more like provide a framework which can be extended and
configured by experts to provide vhost behaviour.
However I'm not likely to get round to all of this quickly, and if it isn't
wanted or needed I'm happy enough to not add it. :-)
d
***************************************************************************
The information in this e-mail is confidential and for use by the addressee(s) only.
If you are not the intended recipient (or responsible for delivery of the message to
the intended recipient) please notify us immediately on 0141 306 2050 and delete the
message from your computer. You may not copy or forward it or use or disclose its
contents to any other person. As Internet communications are capable of data
corruption Student Loans Company Limited does not accept any responsibility for
changes made to this message after it was sent. For this reason it may be
inappropriate to rely on advice or opinions contained in an e-mail without obtaining
written confirmation of it. Neither Student Loans Company Limited or the sender
accepts any liability or responsibility for viruses as it is your responsibility to
scan attachments (if any). Opinions and views expressed in this e-mail are those of
the sender and may not reflect the opinions and views of The Student Loans Company
Limited.
This footnote also confirms that this email message has been swept for the presence of
computer viruses.
**************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
