On Wed, 22 Jan 2020 at 13:21, Florian Schmaus <f...@geekplace.eu> wrote:
> On 22.01.20 13:59, Dave Cridland wrote: > > > > On Wed, 22 Jan 2020 at 11:46, Florian Schmaus <f...@geekplace.eu > > <mailto:f...@geekplace.eu>> wrote: > > > > On 21.01.20 17:05, Jonas Schäfer (XSF Editor) wrote: > > > The XMPP Extensions Editor has received a proposal for a new XEP. > > > > > > Title: Inbox > > > Abstract: > > > This specification proposes a mechanism by which clients can find a > > > list of ongoing conversations and their state. > > > > > > URL: https://xmpp.org/extensions/inbox/inbox.html > > > > """ > > Any counter of unread SHOULD be accurate, however client implementors > > please note that due to heuristics involved and other issues these > > counters can be inaccurate at times. > > """ > > > > I am aware that those counters are inherent racy, but could we > introduce > > a boolean attribute 'accurate', defaulting to false, to signal that > the > > counter data is accurate (at the time of determining the number). > > > > > > I don't *think* they're racy, particularly. I mean, yes, if you get an > > inbox at the same time another message is send or another is > > acknowledged, sure, but otherwise not, and even then it's not totally > > clear that has to be racy. > > > > I was more thinking in terms of the server just not knowing the client > > state. > > > > So anyway, the heuristic inaccuracy I was considering is really a matter > > of saying to client developers that if the server says you have two > > unread messages but you know by your local cache/state you've seen one, > > then you're probably right. > > That makes sense. However, it is not what I had in mind when I read the > sentence quoted above. To clarify, will the number returned by the > server always be exact and accurate (from the servers point of view)? Or > do we have an RSM like situation where the number may be inexact? If it > always will be exact/accurate, then there is indeed no reason to signal it. *waves hands deperately* We've seen (in the field) cases where the number isn't accurate from the user's perspective. Maybe I'm just being hypersensitive to this issue; we use the number of conversations with unread messages in to set the badge number for notifications on iOS, for example, and if this is out of sync with the user's perception (and the client's) this causes pain, anguish, and support calls. Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
