> > On a related note, as I believe I've mentioned I'd like to change the way > > that RemoteDelivery works. Rather than have RemoteDelivery handle its own > > queuing, I'd like to push that out a level so that any matcher/mailet can > > benefit from that capability. For example, if a DNSRBL matcher failed, the > > operation could be requeued.
> I would not mind putting that on my list Let's agree that the "lists" we're putting into the Wiki are communal. I put them in as "X's list" just make it easier for folks to find and merge (because I was too lazy to do that myself), not to imply ownership. If I were to say that something is on my list, it would be because it is something I'm interested and/or willing to do, not something I feel is mine to do. Right? :-) > most stuff that concerns RemoteDelivery has my interest ;-) :-) > Do you have more detail of how you envision this requeing service? I had started playing with an AbstractSpooled mailet, which was derived from the RemoteDelivery mailet, factoring out all of the generic code from the delivery-specific code. The obvious quickly became apparent: what you end up with is wanting to retry/schedule calls to the service method, and this ought to be available to both matchers and mailets. Plus, we want to be able to use a pool of workers. My thought is to incorporate it directly within the container (Processor -- whether or not that is a special mailet type is orthogonal). We would need a means by which the matcher or mailet can indicate the need for a retry, but the schedule would be configured in the container. For a mailet, we COULD have a magic RETRY state, just as we have a GHOST state, but the matcher interface doesn't support that approach. A better idea, I feel, might be to use something like: package org.apache.mailet; class RetryException extends javax.mail.MessagingException { ... } That would handle both matchers and mailets, and we could put useful information into the exception, such as the reason for the retry. For that matter, we could allow some retry information to be provided. I'm still thinking that as a general rule, the schedule ought to be configured external to the matcher/mailet, but can imagine that in some cases the matcher or mailet will have better information, particularly if the scheduling is dynamic. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]