[Standards] Proposed XMPP Extension: Inbox

Florian Schmaus 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
>     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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200122/c548150b/attachment.sig>


More information about the Standards mailing list