On 08/23/2011 09:14 AM, Justin Karneges wrote: > On Monday, August 22, 2011 05:12:54 AM Sergey Dobrov wrote: >> On 08/19/2011 04:55 AM, Justin Karneges wrote: >>> On Thursday, August 18, 2011 05:10:58 AM Goffi wrote: >>>> - the ability to get missed items between the last time a contact was >>>> disconnected and the time it reconnect >>> >>> I have a protocol flow for reliable pubsub that I've not yet publicized, >>> but essentially the idea is to include Result Set Management (XEP-0059) >>> UID values in pubsub event notifications. The client can then notice if >>> it missed an item and use iq-get to catch up. >>> >>> Maybe this could go in some "RSM with PubSub" XEP that sorely needs to be >>> written. >>> >>> Justin >> >> You forgot that we need to know about item retraction as well as about >> item publishing. The same thing about item update. The possibility to >> get items by date and time is good but it's not cover these problems and >> it's not necessary at this time from my point of view. > > 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. That would not work because it is equal to the item update with the blank payload but how could you know that the item was updated?
> > 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. Protocol needs many edits anyway. For example, it very useful to see a publisher of an item but XEP-60 doesn't give us good explanation how to determine if pubsub service can send such notifications. > > Item publish and update are fine though, right? Or what are you thinking > about > them? Publish is ok since we have RSM. Update has the same problem as retract. >From my point of view, the best solution is node journal but I can't be sure since that idea was not discussed. > > Justin > -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
