[Standards] Exact hint for Result Set Management
flo at geekplace.eu
Thu Jul 12 11:24:30 UTC 2018
On 12.07.2018 12:39, Kevin Smith wrote:
> On 12 Jul 2018, at 11:23, Matthew Wild <mwild1 at gmail.com> 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:
>>>>> I recently submitted PR #672 to the xeps repo
>>>>> to make users of RSM, like MAM, aware whether the result is exact or
>>>>> not. It received some scepticism from the council members in today's
>>>>> council meeting. I am to blame here as I thought the abstract motivation
>>>>> in the commit message was enough. It appears it wasn't.
>>>>> While I think multiple applications could exploit that information, my
>>>>> particular motivation was MAM. Consider the scenario where you have a
>>>>> master archive and a local archive. The local archive may have multiple
>>>>> holes at unknown locations. Now you want to sync your local archive from
>>>>> the master using MAM/RSM.
>>>> I'm not keen on this solution for the premise you've given.
>>>> I don't believe that when using MAM correctly you would ever end up
>>>> with "holes at unknown locations" in your local archive. I don't think
>>>> that encouraging people to use a "bisection algorithm" is the right
>>>> thing to do.
>>> 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.
> And, as specified (optional but with no default or meaning for a missing flag) it seems unhelpful
As Georg mentioned yesterday, the default is exact="maybe". There is
also a sentence explaining the semantic of the missing hint:
> and as it adds a SHOULD, in a Draft XEP, with no namespace bump or
> discovery, it’s adding ambiguity and confusion..
I don't think that this is true, but we certainly can talk about making
it just a recommendation if it is a blocker.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 618 bytes
Desc: OpenPGP digital signature
More information about the Standards