Bob Wyman: [[[ I am particularly interested in �Atom-related� comments at this point. For instance, you�ll notice �Delete� messages in the feed. We�ve talked about �Delete� or �Retract� capability often in the past and I�ve usually argued against it. However, it turns out to be necessary with this kind of feed since often earthquake reports are retracted as erroneous � often as the result of telemetry glitches. How should we best handle the need for �Delete� in this context? What will be easiest for clients to handle? ]]]
If you consider the Atom entry stream as a set of idempotent synchronization messages, "delete" can be represented as an empty entry with the same id as a previous entry. (This is a very nice model to work with, in my experience: you have a set of inputs representing state, a set of inference rules, and an output state. Note that regardless of whether the entry stream represents a sampled state or discrete events, you want the loop to be closed at the consumer side, according to end-to-end principle.) Ziv Caspi � cell: +972-53-668-751 ��� web: http://radio.weblogs.com/0106548/
