On 8/22/11 8:14 PM, "Justin Karneges" <[email protected]> wrote:
> The basic solve for item retraction is for the server to keep deletion markers > around. For example the server could clear all content of an item and flag it > as deleted, but keep it in the same position in the item list. This way > retracted items can be reported in iq responses. > > Unfortunately XEP-0060 never discusses sending <retract> in an iq response > where <item> normally is, so I am not sure if this would be allowed today > without a protocol update. Alternatively, retractions could be represented > within the items themselves. For example if you were using Atom, an empty > <entry> element may suffice to indicate deletion. > > Item publish and update are fine though, right? Or what are you thinking > about > them? I was hoping for something more like atomic-subscribe-and-send-updates as a subscription option, so that the client's notification handling didn't have to change. The server could then just send normal retracts in that flow. If there was another subscription option that says "it's ok to send me multiple notifications in the same message", the server could intelligently batch the notifications together for clients that have added the extra foreach loop. -- Joe Hildebrand
