On Wednesday, August 24, 2011 03:34:27 AM Sergey Dobrov wrote: > 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.
Yes, if tracking changes is needed then the node should have a way of offering items ordered by modified time. Being able to query for items using different kinds of orderings would be useful though, so I didn't want to stipulate that pubsub with RSM must always be ordered by modified time. Rather, each node would have some sort of natural ordering depending on intended purpose, and if we want the client to be able to select among multiple orderings offered by a node then that would be a separate extension or scheme. For example, my XEP-0303 proposes selecting ordering using special node name suffixing, such as "?order=-created" to indicate created time descending order. But this is just one way to go about it. Justin
