On Wed, 8 Jan 2020 at 18:23, Marvin W <x...@larma.de> wrote:
>
>
> On 1/8/20 5:25 PM, Florian Schmaus wrote:
> > After briefly reading this thread, it is my impression that Dave wants
> > to pursue a generic approach to referencing/linking/fastening messages
> > and the related MAM retrieval, while you argue that a use-case specific
> > approach is required (at least in some cases). Is that summary correct?
>
> I think a generic approach of referencing/linking/fastening is possible.
> XEP-0367 already does so in a very generic way. Related MAM retrieval
> would also be possible generically.
>
> What I don't think is possible or makes sense in a generic way is
> "summarizing". This is what makes two <reaction emoji="π" /> from two
> senders being presented through MAM as <reaction emoji="π" count="2" />
> (not to be taken verbatim) and what ensures that you only retrieve the
> latest edit with an message.
>
>
That's a mischaracterization of intent, there - it provides a count of
similar fastenings and the last fastening, which happens to be all you need
(for initial UX) for both reactions (and similar) and edits.
So you get:
<result>
<forwarded/>
<applied count='2'>
<reaction emoji="handwave"/>
</applied>
<latest>
<reaction emoji="handwave"/>
</latest>
</result>
In which case the <latest/> is redundant for UX, or you get:
<result>
<forwarded/>
<applied count='2'>
<edit/>
</applied>
<latest>
<edit>
<body>I meant this</body>
</edit>
</latest>
</result>
In which case the count is largely uninteresting.
What we've already discussed is that the <latest/> should also have the
archive id of the latest fastening, as well as other information, but this
ought to be sufficient to fetch whatever fastenings you're interested in
full. So for an arbitrary fastening called, say, foobar:
<result>
<forwarded/>
<applied count='2'>
<foobar type='glurg'/>
</applied>
<latest archive-id='12345'>
<foobar type='glurg'>
<new-element>Gargleblaster</new-element>
</foobar>
</latest>
</result>
... the count and lastest are neither enough, potentially - but you do now
have the information on:
a) Do you need to fetch more of them? (is count more than 1)
b) Have you done so already? (is latest already in your cache)
This is the rationale behind these two. The fact they happen to be useful
for reactions and edits just happens to be convenient.
For completeness:
<result>
<forwarded/>
<applied count='2'>
<reaction emoji="handwave"/>
</applied>
<applied count='2'>
<edit/>
</applied>
<applied count='2'>
<foobar type='glurg'/>
</applied>
<latest archive-id='12345'>
<foobar type='glurg'>
<new-element>Gargleblaster</new-element>
</foobar>
</latest>
<latest>
<edit>
<body>I meant this</body>
</edit>
</latest>
<latest>
<reaction emoji="handwave"/>
</latest>
</result>
> If XEP-0422 really was generic and didn't have any semantic,
(surely a XEP that is totally generic and has no semantic is entirely
useless?)
> it should
> be OK to do something like this:
>
> <message from="sender@server.example">
> <apply-to xmlns="urn:xmpp:fasten:0" id="message-to-react-to">
> <reactions xmlns="urn:example:reactions:0">
> <reaction>π</reaction>
> <reaction>π£</reaction>
> </reactions>
> </apply-to>
> </message>
>
>
That is, however, just equivalent.
> Or even:
>
> <message from="sender@server.example">
> <apply-to xmlns="urn:xmpp:fasten:0" id="message-to-react-to">
> <external name="reactions"
> element-namespace="urn:example:reactions:0" />
> </apply-to>
> <reactions xmlns="urn:example:reactions:0">
> <reaction>π</reaction>
> <reaction>π£</reaction>
> </reactions>
> </message>
>
>
This, though, is considerably worse. Here, the server has to search the
entire message twice; once for the apply-to and once for the reaction
element. That is going to be roughly twice as much processing for the
server.
> Which would make the proposed MAM-FC rather useless, even if other
> proposals may be able to handle this just fine. The first is an example
> where the fastening can at least fully decide on their wire format.
I don't see the advantage in this - any flexibility here is bought with
increased server complexity.
> The
> second even has forward compatibility built in, because a future
> replacement for fastening could just also support something like
> external, like this:
>
> <message from="sender@server.example">
> <fasten xmlns="urn:example:fasten:2" id="message-to-react-to">
> <ref name="reactions" ns="urn:example:reactions:0" />
> </fasten>
> <apply-to xmlns="urn:xmpp:fasten:0" id="message-to-react-to">
> <external name="reactions"
> element-namespace="urn:example:reactions:0" />
> </apply-to>
> <reactions xmlns="urn:example:reactions:0">
> <reaction>π</reaction>
> <reaction>π£</reaction>
> </reactions>
> </message>
>
But how do you summarize these in MAM?
You cannot just include them all, it'd result in huge stanzas. If you only
include that there are reactions, you're forcing an additional RTT every
time.
So you need to summarize them somehow.
So far, your only concrete suggestion is that MAM would have to be taught -
individually - how each and every possible fastening would be summarized,
but that means server-side support in code, which seems impractical. For
one thing, it forces a server to actually parse the entire element in many
cases which they otherwise wouldn't be doing.
My counter proposal remains the same - we design fastenings such that they
summarize effectively, and we do so by imposing rules around their syntax.
I don't see this as being substantially different to the way we require
pubsub payloads to be a single element, for example.
Yes, it means that if you want to use a reaction based on the design in
'422, and relied upon by MAMFC, it'll have to have a certain syntax (or at
least, certain syntactic features), and if you also want to try a different
way, it'll look different, and require different code to support.
Dave.
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
