[Standards] Exact hint for Result Set Management

Florian Schmaus flo at geekplace.eu
Thu Jul 12 12:13:02 UTC 2018


On 12.07.2018 12:23, Matthew Wild wrote:
> On 11 July 2018 at 18:25, Florian Schmaus <flo at geekplace.eu> wrote:
>> On 11.07.2018 18:01, Matthew Wild wrote:
>>> On 11 July 2018 at 16:33, Florian Schmaus <flo at geekplace.eu> wrote:
>> So you don't want MAM users to be able to efficiently sync archives with
>> multiple holes by a simple change because you do not want MAM to be used
>> in scenarios where this could happen?
> 
> Just adding this flag will not make servers implement it, so it's
> going to add code and still need a fallback.

True, but at least we have a specified way to signal that the returned
numbers are exact then.

> I believe that ambiguity in how to implement protocols properly is a
> big problem we have. XEPs tend to describe only the wire protocol, and
> if the author of the XEP even had a data model in mind, it's rarely
> (if ever) clear. For example it took me a long time to realise that
> pubsub's model is an (optionally capped) ordered key->value store, and
> that's made clear precisely nowhere in XEP-0060.


>> From a generic, non MAM-specific point-of-view, RSM is eventually used
>> to sync data, and for that you often want to now if the RSM metadata is
>> exact or not. My MAM example is just one illustration of that. It always
>> appeared like an afterthought that RSM does not allow the RSM data
>> originator to signal if the numbers are exact or not. The proposed
>> change tries to fix that.
> 
> I think the intention of RSM's vague numbers is that they were used
> for things like UI (progress bars, etc.) hints only.

I'm well aware why RSM allows inexact results. That is not what this PR
is about.

I simply think it is an oversight that RSM does not signal if the
results are exact or not. That is all I want to address. My suggestion
in current PR does that in a backwards compatible way. If there would be
a RSM namespace bump imminent, then we could do it right and make the
hint mandatory. But I don't think that there is one pending, and I
believe the exact hint does not justify a namespace bump.

- 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/20180712/bf087c0d/attachment.sig>


More information about the Standards mailing list