On 22.01.20 16:20, Dave Cridland wrote: > > > On Wed, 22 Jan 2020 at 13:21, Florian Schmaus <f...@geekplace.eu > <mailto: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> > > <mailto: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*
I am not sure what I did, that made you do so. > 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. I totally get that and I do not argue about that. All I wanted to say is that I probably misinterpreted the sentence from your XEP as a RSM-like situation, where you could get count=100, but there are actually 107 items in the result set. As far as I understand you, this is not the case, but I wanted to clarify that. And hence I asked if the number returned by the server is always exact and accurate from the server's point of view. I am not sure if this reply is supposed to answer my question, since I fail to see the answer here. :( - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
