[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'.

eg:

<iq type='result'
    from='pubsub.shakespeare.lit'
    to='hamlet at denmark.lit/elsinore'
    id='subman1'>
  <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'* />
    </subscriptions>
  </pubsub>
</iq>

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

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

Or?

S.


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:
goo.gl/tQgxP
-------------- 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