Ahh, now I fully understand Noels comments. I started doing accept(Filter) in JDBCSpoolRepository and we do not have complete MaiImpl's in there and even the misused errormessage is not in PendingMessage. But as it is in the underlying db I will just change the sql query and PendingMessage.
I am beginning to understand why this hasn't been done before. --S�ren On Thursday 23 October 2003 08:42, S�ren Hilmer wrote: > I can see, why you wish to keep lastUpdated as the time the mail was > actually put in the spool for diagnostic purposes. > > I was hoping to keep the changes local to RemoteDelivery, but this boils > down to that not being possible. > > So I will start working on Spool.Filter and Spool.TimeFilter. and > accept (Filter); > > But let be just be sure this is what you mean: > > Spool.accept(TimeFilter) will consult the supplied TimeFilter with the mail > as input, which in turn uses the lastUpdated time of the Mail and its > current retrycount (which exists in the errormessage), and based on these > it determines if the Mail is ready for retry. > > This is quite elegant IMO as the concrete TimeFilter implementation can > reside in RemoteDelivery, so the "misuse" of the errormessage for the > retrycount is localized in RemoteDelivery. And it requires minimal changes > to Spool. > > --S�ren > > On Thursday 23 October 2003 00:19, Noel J. Bergman wrote: > > > > Mind you, I'd also like to see Spool.accept() return the message, not > > > > the > > > > > > key. There are exactly two calls to Spool.accept()/accept(long) in > > > > James. > > > > > > In both cases, we immediately follow up by retrieving the message, > > > > but > > > > we > > > > > > have a much more complex synchronization process because of the two > > > > stage > > > > > > access method. > > > > > > Agreed. > > > > > > But to address the fundamental challenge, I would say this is a good > > > use of mail attributes. Sounds like we would need to provide a query > > > interface on the repository for this, but really you want to set a date > > > on the mail that is not last updated, but independent of any data we > > > store right now. > > > > I had thought of that, but it would mean that: > > > > (a) scheduling would only work on systems with attributes enabled > > (b) scheduling would require reading the attributes, too. > > > > We already have the lastUpdate time. We can easily add the retry count > > to the same query, which we'll want, anyway. From that, we can compute > > the delivery time. > > > > What we could do is establish something like: > > > > Spool.accept(Filter filter) > > > > Spool.Filter would be an static inner interface of the Spool interface, > > so we tie the concepts. If we have a Spool.TimeFilter interface, we > > could check for that interface, which just tells us that all we need are > > the time and retry count. Then we can call it, perhaps > > TimeFilter.accept(long time, int retries) to see if the current pending > > message is suitable. I dislike the lack of polymorphism, but the JDBC > > Spool uses a very lightweight object that isn't a full MailImpl. > > > > Anyhow, that's an idea. Seems like something useful (and reusable) there > > if we tweak it. > > > > --- Noel > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] -- S�ren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ Fax: +45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 �byh�j Email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
