Noel J. Bergman wrote:
This is an approach to implement the scheduling aspect of my "New Approach
to Spooling" proposla. It is intentionally compatible with the existing
Mailet API.
As a reminder, I already made comments to the "New Approach to Spooling"
and I have a (stalled, maybe working) work in progress on the same area.
The change will consist of three parts: a processor, a mailet and a utility
class. The processor would be defined, to use a simplified example without
configuration options, as:
<processor name="SCHEDULER">
<mailet class="Scheduler"/>
</processor>
have the processor name "SCHEDULER" some special meaning? I don't
understand it from this mail.
which does nothing for you unless you know what the Scheduler mailet is, how
messages get there, and where they go afterwards.
The Scheduler mailet will be derived from the part of RemoteDelivery that
receives a message on a spool thread, and has a separate thread processing
an internal queue. We won't need more than one scheduler thread. When a
message's schedule time occurs, the mailet will post it to the designated
destination.
[...]
The schedule object would be constructed from a retry schedule such as the
one we have for RemoteDelivery. Actually, I'll do an abstract class with
the code for scheduling and an abstract method "nextTime" method, and then a
specific implementation making use of the code from RemoteDelivery, to
separate mechanics from policy. RemoteDelivery would receive messages and
perform something like:
if (!deliver(mail) && !schedule.retry(mail)) {
process a bounce
}
How do you handle the accept? Currently the spoolrepository interface
does not give you access to mail attributes.
In practice, how do you ignore mails until the next attempt time? What
is the message state and the repository of delayed messages?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
