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

Simon Tennant simon at buddycloud.com
Mon Jul 28 17:14:01 UTC 2014


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.

I remember Kev having some very wise ideas about how to elegantly solve
this during the FOSDEM bus trip back to A-loft (but that could have been
the beer speaking).

S.


On 28 July 2014 15:14, Ashley Ward <ashley.ward at surevine.com> wrote:

> On 28 Jul 2014, at 14:06, Simon Tennant <simon at buddycloud.com> wrote:
>
> For buddycloud channels, we're looking for a sensible way to store a users
> read state per publish-subscribe node.
>
> For example:
>
>    - a pub-sub node has a large number of posts
>    - user reads some of them from oldest to newest on one device
>    - client stores "read up to this postID/timestamp" on pub-sub server.
>    - user carries on unread posts on a second device.
>
> In this case we're simply trying to store a timestamp/or postID of the
> newest message that the user has read up to (vs IMAP style un/read per
> post).
>
> Is there a sensible way to implement this per node, per user?
>
>
> How about on a PEP node for the user? Although this is then taking it out
> of the buddycloud stack.
>
> Alternatively, to keep it within the buddycloud stack you could store it
> on a separate node within the user’s personal channels:
>
> e.g.
> /user/user at domain.com/readstatus
> or something like that
>
> You could use the node id as the item id (for easy retrieval) and some
> information within the payload (such as last item id read, when it was
> read, maybe even what device it was read from).
>
>> 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/20140728/2f49f94e/attachment.html>


More information about the Standards mailing list