On 08/26/2011 01:08 AM, Justin Karneges wrote: > 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>. I don't sure that it's fine decision since blank entry is not equal to a retracted item. Anyway, it needs to be described in XEP-60.
> > 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> > That is seems to be ok. >>> 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. But where determined what is "dynamic" node? How servers can implement it without specification? > > Justin > -- With best regards, Sergey Dobrov, XMPP Developer and JRuDevels.org founder.
