[Standards] Unread syncing

Michal Piotrowski michal.piotrowski at erlang-solutions.com
Wed Dec 14 15:04:29 UTC 2016


On 14 December 2016 at 14:50, Kevin Smith <kevin.smith at isode.com> wrote:

> On 14 Dec 2016, at 11:46, Michal Piotrowski <michal.piotrowski at erlang-solu
> tions.com> wrote:
>
>
>
> On 2 December 2016 at 18:18, forenjunkie <forenjunkie at chello.at> wrote:
>
>> Ah now im understanding, basically the server should give you a list of
>> contacts to query for messages.
>>
>> i would see this as a simply addition to MAM.
>>
>
> Would you see it as a new parameter to MAM query? or rather a completely
> new kind of iq to MAM service?
>
>
> What I’m currently speccing up after a few side discussions with folks
> recently is actually something that replaces the initial bind and does all
> the bits that need doing for multi-client at once. I need to find a couple
> of hours to finish writing it up so we can get it in the inbox and start
> discussion.
>
> The Archive already could know what messages you read, because of
>> chatmarkers. it would only need to hold the last read marker stanza id for
>> every contact in roster, and perform some SQL magic on query.
>>
>
> I can think of a situation where there is no roster (on XMPP server) but
> still there is archive and we want to get list of contacts with unread
> messages.
>
>
> I like Kevin's idea with the iq and list of unread messages in a result.
> Also I think it would be beneficial for clients to have not only id of the
> unread message but also the content.
> This could be optional, of course, but in some cases getting the unread
> message content would make UI update easier.
>
>
> I think the content of the messages is fairly straightforward to get from
> a MAM query immediately afterwards. I was originally thinking that you’d
> get sent the messages themselves, but I’m coming to the conclusion that it
> doesn’t buy much, and makes the protocol more complex. I guess we’ll see
> once I’ve finished speccing it whether this works or not.
>
> The client doesn't have to query the archive if it only wants to display
> part of the unread message content on the UI.
>
>
> That’s true, but is it significantly harder for the client to send that
> query, if the server has already told it exactly the IDs it needs to query
> between?
>

For me as a server dev it doesn't make much difference if the client asks
for the message or not.
>From my experience working with client devs (mostly mobile recently) I can
say that they (who I worked with) would like to have everything what's
needed in single result so that the app doesn't have to send additional
requests.
I agree this is not always possible and makes the protocol more complex.
I just wanted to share my experience regarding this.


>
>
/K
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20161214/bd436a93/attachment.html>


More information about the Standards mailing list