[Standards] Proposed XMPP Extension: Inbox

Florian Schmaus flo at geekplace.eu
Wed Jan 22 13:21:06 UTC 2020


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>> 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.

- 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/78f72e0f/attachment-0001.sig>


More information about the Standards mailing list