[rabbitmq-discuss] A new exchange type

[Ben Hyde]

This cache of last msg of a given key exchange type is useful only if  
the messages are
absolute, rather than a series of diffs on the state of the thing  
denoted by the key.  Is that
the typical pattern in these parts?

Revision numbers are the usual thing once you have diffs.  So by  
extension
you could build an exchange that stands willing to replay the messages  
an
observer missed since he was last online.  That's more what you desire  
if
your messages are atom feeds, say.

There are delicacies about assuring that you don't act on stale data.   
People
often forward chain on message arrival.  Which is cool if your  
messaging substrate
is fast and has tiny buffers; but these replayed messages are not  
fresh.  I guess
it might be a good rule of thumb to add guards to enforce sell-by- 
dates on all
the message handling.  Is that common?

I find there then are often three modes.  Coming online, online, and  
running
behind.  The last of these is the mess that arises when your on the  
other side of a
slow link; and there tend to be too many ways that happens; but in  
that scenario
you want somebody downstream to be merging, condensing, or  
summarizing, or
something.  Something else a stateful system component might provide.

Finally in system's I've build the diffs fly fast and furious,  When  
new observers
come online they talk to other observers (possibly a master observer)  
to bring
their model of the state of the world up to date  That step tends to  
involve moving
a lot of data.

I don't know if all that means this should be in the broker or not.