On 08/24/2011 01:38 AM, Justin Karneges wrote: > On Tuesday, August 23, 2011 04:34:12 AM Sergey Dobrov wrote: >> On 08/23/2011 09:14 AM, Justin Karneges 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. >> >> 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? > > I'm still unsure what you're saying but I'll try to guess: do you mean to say > that you cannot determine the difference between a publish vs update, unless > you have a local copy of the item to compare with? If so, I have found that > in many situations this does not actually matter. Can you share a use case? No, I tell you that even if I will be able to receive items according to the publish time then I can't find if some items was updated before that time. But if it's by modify time then yes, all seems to be ok except of retract.
> >> From my point of view, the best solution is node journal but I can't be >> sure since that idea was not discussed. > > True. I am trying to avoid this if possible. My stance is there is nothing > wrong with using a journal to implement pubsub, but ideally pubsub-using > protocols should not be so complex that they require a journal-based > implementation to participate. I don't insist on journal, I just need a reliable way to retrieve node changes and I can't think up another way. > > Justin > -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
