On Thursday, August 25, 2011 07:27:16 AM Sergey Dobrov wrote: > On 08/25/2011 03:36 AM, Justin Karneges wrote: > > 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?
At the moment, I feel this is best done by having a node-specific item format indicating deletion. For Atom-based pubsub nodes, this could be contentless <entry>. But I think it would also be good to see about getting <retract> into the spec for iq exchange. > And how I can > understand if I missed something and should to re-request items from node? Each pubsub message event should contain two RSM ids: the id of the item contained in the event as well as the id of the item that directly precedes it according to the item ordering. Whether by iq or message, the client would remember the last known RSM id. If a message event is received and the "id of preceding item" in that message does not match the last id known by the client, then the client can choose to catch up by using iq to fetch items since the last known id. We could use SHIM for this: <headers xmlns="http://jabber.org/protocol/shim";> <header name="RsmId">64fc10d2</header> <header name="PreviousRsmId">f4ac5920</header> </headers> > > 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. Maybe you don't need it, but I need it. :) The commenting protocol requires both created time ordering (for application display render) and modified time ordering (for tracking updates). But, I am open to discussing alternatives that don't involve dynamic node names. Justin
