[Standards] Proposed XMPP Extension: Inbox
flo at geekplace.eu
Wed Jan 22 15:45:51 UTC 2020
On 22.01.20 16:20, Dave Cridland wrote:
> On Wed, 22 Jan 2020 at 13:21, Florian Schmaus <flo at geekplace.eu
> <mailto:flo at geekplace.eu>> wrote:
> On 22.01.20 13:59, Dave Cridland wrote:
> > On Wed, 22 Jan 2020 at 11:46, Florian Schmaus <flo at geekplace.eu
> <mailto:flo at geekplace.eu>
> > <mailto:flo at geekplace.eu <mailto:flo at 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
> > >
> > > 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
> > 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
> > 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
> > 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
> > 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. :(
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 618 bytes
Desc: OpenPGP digital signature
More information about the Standards