2009/11/8 Aidan Skinner <ai...@apache.org> > The original message is delivered and persisted as normal. The > exchange would hold onto a copy of that message, and generate an > entirely new, identical one at the specified interval. > > Putting this logic at the exchange level seems better to me because > it avoids further complicating the subscription implementation. It'll > also map a bit cleaner into 1.0 semantics (as a non-destructive link). > > I don't think we would need to complicate subscription implementation unless we wanted to implement this by having selectors which compared message fields to the present time (or some other condition that would need to be periodically reevaluated). I was thinking that we would implement like TTL - i.e. the message state on the queue is changed when the time-driven condition changes (in this case when it becomes live)... As happens already in the queue, the state change will cause the subscribers to go re-examine the message to see if they can now deliver it. Other than sorting out how we do timed events a bit, this seems like a fairly minor change at the queue level.
Having exchanges that retain state would be a big departure, and as Robert points out would complicate persistence. From a 1-0 point of view, there will be no such thing as exchanges, so I'm not sure I really see the advantage there. Basically the difference is between hard-coding the entry point/address for the message (by fixing the exchange type) or adding a new capability to queues. I much prefer the latter, and I also think it will be cheaper to implement Cheers, Rob
