On 08/25/2011 03:36 AM, Justin Karneges wrote: > 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. Yes, it's sounds ok but what with retracts again? And how I can understand if I missed something and should to re-request items from node?
> > 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. I don't have enough time to dive into XEP-303 enough but I don't think that this is a good idea to use "dynamic" pubsub nodes without separate XEP for it. Again, I don't think that different ordering is really need at this time. > > Justin > -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
