Hi! XMPP Extensions Editor wrote: > Version 0.1 of XEP-0312 (PubSub Since) has been released.
Great that this is approached by somebody! > Abstract: This specification defines a publish-subscribe feature that > enables a subscriber to automatically receive pubsub and PEP > notifications since the last logout time of a specific resource. For buddycloud we use MAM[1] so far but gave the problem some thought before. 1. Specifying a relative timespan instead of absolute timestamps avoids the need for global clock synchronization. That is smart. Until now we used the timestamp of the latest pubsub notification (ATOM payload). 2. I've been very reluctant to employ <presence/> for requesting history, especially presence broadcasts. Presence will be resent upon changing the online status & text. It could be important to exclude the XEP-0312 information in all but the very first presence stanza. Moreover, presence can be redistributed by a user's server. This happens only on presence probes, right? Is this still safe enough? What if the pubsub service needs to be restarted, subsequently probing for presence of its subscribed users? It will needlessly replay history. Admittedly in buddycloud clients only communicate with their one "inbox" pubsub service, so the MAM <iq/> doesn't add much complexity. I can see a reason for <presence/> when dealing with many entities though. 3. MAM specifies replayed notifications to be sent in XEP-0297ish envelopes, despite that there's no forwarding going on. The history sender is the notification source. XEP-0312 doesn't specify that and I guess there is no reason for it? 4. RSM with <presence/> and multiple <message/> stanzas in response needs to be specified clearly. RSM is only straight-forward for <iq/>-based extensions such as MAM. Stephan [1] http://doomsong.co.uk/extensions/render/message-archive-management.html
