On Wed, 2011-08-24 at 17:34 +0700, 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.
Are you saying here that you want intermediate changes for the same item (i.e. the same ItemID) that took place while the client was not online to receive the notifications? If so, the model in XEP-0060 is that each update to an item is a complete replacement for that item, so a service will not keep record of previous 'versions'. If you really want that you should probably use unique identifiers for each update. In the field of microblogging I don't see a particular use case for this. Microblog entries typically don't change once posted, and even if they would, an end-user would probably only be interested in the most recent version. For more expanded use cases in Federating Social Networks (beyond microblogs) that cover other social objects (regular blogs, stories, pictures, people's profiles) updates are more common. Let me expand on a real-world example. At Mediamatic we've built a network of sites that federate using (amongst others) XMPP PubSub. The sites are basically collections of Things that have relationships or Edges between them, with a particular predicate. Very semantic web, RDF-like. For exchanging Things, we make an Atom representation of the Thing with all of its 'outgoing' Edges, encoded as <link/> elements. (Example: http://www.mediamatic.net/atom/24879). Each Thing has its own node (xmpp:pubsub.mediamatic.net?;node=id/24879). In this setting, for each update (changed title, new relationships) we just push the whole representation to the subscribing sites (ItemID 'current'). Upon reception, the local shadow representation is entirely replaced with the version just received. We did think about sending around delta's at some point, especially for edge updates, because the pings are really fat. Up till now, we haven't pursued this because it makes the operation more fragile. If you missed an update, you have to figure what you've missed, likely by replaying a journal. Alternatively, I could think of having a more explicit subscription, where you have the publishing service filter out certain bits (unwanted edges with particular predicates) in the Atom in the notification, and only send updates for 'fields' you are interested in. We also played with the thought of having separate items for derived (meta) data for each thing. These could hold information on the amount of comments, likes, visits and various 'ratings', that you might want to show on the federated sites. We haven't pursued this mostly because lack of time. I'm also not sure about how to encode this information, as items in a node typically have their payload in the same namespace. Encoding this meta data in Atom might be somewhat of an overkill. > >> 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. In our case, we don't retract items, but do send node deletes (sometimes with a redirected to another Thing, when there was a move between sites or two things have been consolidated into one). I suppose that wouldn't work nicely in your setting, because all of our subscriptions are explicit. We do have something akin to collections or 'generic subscriptions', which act more like an Atom Feed. There we create or update items based on the atom:id inside the payloads, and don't actually look at the ItemID. Deletes are not published in this setting, but this could probably be done by doing an explicit subscription on each item. Apparently we haven't really had much incentive to solve this, yet. -- ralphm
