[Standards] [buddycloud-dev] XEP-0060 and mark read up to point.

Simon Tennant simon at buddycloud.com
Tue Jul 29 09:57:19 UTC 2014

Thinking about how a client will usually work,

   - you start off with a fetch-subscriptions,
   - then fetch new posts.

So a different approach could be to do a 'fetch subscriptions' and
read-up-to-enabled-pubsub server will then also return a 'read-state'.


<iq type='result'
    to='hamlet at denmark.lit/elsinore'
  <pubsub xmlns='http://jabber.org/protocol/pubsub#owner'>
    <subscriptions node='princely_musings'>
<subscription jid='bernardo at denmark.lit' subscription='subscribed'
subid='004-yyy' *read-up-to='2012-08-21T22:31:20+0000'* />

and at client-defined intervals a stanza is sent to the pubsub server with

<iq type='set'
    from='francisco at denmark.lit/barracks'
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
        jid='francisco at denmark.lit' *read-up-to='2012-08-21T22:31:20+0000'*



On 29 July 2014 10:31, edhelas <edhelas at movim.eu> wrote:

> Why make it difficult when you can make it simple ?
> We could create a new XEP by looking how the IMAP protocol works. Each
> subscribed user of a node can send a little "read" stanza to the server.
> Then the next time eh will request the items of the the node, the server
> can add a little tag to show him that this content has already been read.
> We can also add specific stanza like :
> - Mark all read
> - Mark read until this specific date
> But this should be resolved server side and I personnaly dont like the
> idea to track these data with an another node, we will have serious
> consistancy issues (like we already have with the Bookmark XEP).
> edhelas
> On lun., juil. 28, 2014 at 7:18 , Ashley Ward <ashley.ward at surevine.com>
> wrote:
> On 28 Jul 2014, at 18:14, Simon Tennant <simon at buddycloud.com> wrote:
> IMHO this is something that should be solved in that node rather than
> running parallel nodes or adding a PEP dependency. Almost like returning a
> different metadata key-value pair to each requesting JID.
> Now you mention it, it feels like it’s actually metadata on the
> subscription (rather than the node), so perhaps storing it in the
> subscription configuration might be more appropriate? — Ash

Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140729/44972d08/attachment.html>

More information about the Standards mailing list