On Friday, August 19, 2011 10:10:01 AM Joe Hildebrand wrote:
> On 8/18/11 2:55 PM, "Justin Karneges"
>
> <justin-keyword-jabber.093...@affinix.com> wrote:
> > I have a protocol flow for reliable pubsub that I've not yet publicized,
> > but essentially the idea is to include Result Set Management (XEP-0059)
> > UID values in pubsub event notifications. The client can then notice if
> > it missed an item
> > and use iq-get to catch up.
> >
> > Maybe this could go in some "RSM with PubSub" XEP that sorely needs to be
> > written.
>
> I like the direction you're heading with this. While we're at it, we need
> something similar for PEP that uses date/timestamps on implicit subscribes,
> since one implicit subscription goes to multiple publishing nodes, each of
> which have different RSM ids. The hope is that you could cache between
> sessions, and only receive PEP updates for things that have changed. This
> would be a huge win for XEP-292 PEP-based vCard, particularly if avatars
> are included.
To fetch items since some timestamp, I'm encoding that in the item retrieval
request using client-meaningful RSM ids. For example, you could do an iq-get
for items since RSM id "time:{isodate}". This type of id would only be used
in requests. (Note: I'm open to using a different approach for letting the
client specify positions, but this seemed simple enough).
In the context of PEP, it would just be a matter of putting this same type of
position spec into the subscription request, and then each remote node would
reply with all items since that time (or just the one item only if it has
changed, I think PEP is always singleton?).
> One thing we have going for us is that a re-publish of an existing item (by
> id) replaces the previous version, so a little bit of overlap between
> sessions is ok
Indeed. In my case I consider a time-based query to be inclusive, so as to
not miss updates occuring within the same second. In the rare case you pick
up the same item again, it's harmless.
Justin
