Hi,
yes, in case of a merge request it would be rather easy to define a text format. Everything can be represented in human readable terms, even random ids :) And bots are obviously free to also accept a text-based command to perform an action. Actions are just a single-click solution for convenience.
Verbosity is something that may sometimes be desired, but sometimes duplicate or annoying. Take the example of the merge again: as soon as you select the "merge" action, the bot performs the merge and then probably sends a new notification, stating that the mr was merged. In that case, having a plaintext "Merge MR!3" would be duplicate and noisy. Another example are polls: if you start a poll in a MUC with hundrets of users, you don't want hundrets of "+1"s or "-1"s to be spammed everywhere. Instead, when the poll ends, the bot would print a summary of the votes. Here the missing plaintext is a "feature".
Gesendet: Dienstag, 21. April 2020 um 14:23 Uhr
Von: "Marvin W" <x...@larma.de>
An: standards@xmpp.org
Betreff: Re: [Standards] Proposed XMPP Extension: Quick Response
Von: "Marvin W" <x...@larma.de>
An: standards@xmpp.org
Betreff: Re: [Standards] Proposed XMPP Extension: Quick Response
Hi,
To me that still sounds like the only major difference is that actions
are not backwards compatible.
I understand that action IDs can be just random, however I wonder what
the usecase of such is that couldn't be realized using a human-readable
text.
Looking at the example in the XEP, the action id = response value of a
an action/response labeled "Merge now" for a merge request with id 3
could just be "Merge MR!3" which is both human and bot readable. I think
something is wrong with an action if it cannot be described in
human-readable terms.
With regards to fallback, I was thinking that I'd like the fact that I
performed an action be visible on other clients (through MAM/carbons)
even if they don't support this new XEP. For Responses this works but
for Actions it doesn't.
Marvin
On 4/21/20 1:18 PM, synd...@web.de wrote:
> Hi Marvin,
>
> I'll try to summarize the difference between Responses and Actions:
>
> A Response is supposed to be exactly equivalent to a "manual" text
> response, without any magic implied. That is, manually typing "yes" in a
> client that doesn't support Quick Response is 100% equivalent to
> selecting the "yes" Quick Response in a client that supports the XEP. An
> implication of the absence of "magic" here is, that Responses only apply
> to the most recently received message, because without magic there is no
> "reference" from the response to the original message.
>
> Actions are not compatible with clients that don't support Quick
> Response, as they require "understanding" the <action> element and
> responding with an <action-selected>. Because clients are free to
> generate unique ids here, the selection of an action is not limited to
> the last message, there is no problem relating the response to the
> original message. A "fallback" body is something that bots can choose to
> do anyway, by allowing to trigger the action via a plaintext response
> too (or comparable).
>
> Hope that clears it up,
> Syndace
>
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
To me that still sounds like the only major difference is that actions
are not backwards compatible.
I understand that action IDs can be just random, however I wonder what
the usecase of such is that couldn't be realized using a human-readable
text.
Looking at the example in the XEP, the action id = response value of a
an action/response labeled "Merge now" for a merge request with id 3
could just be "Merge MR!3" which is both human and bot readable. I think
something is wrong with an action if it cannot be described in
human-readable terms.
With regards to fallback, I was thinking that I'd like the fact that I
performed an action be visible on other clients (through MAM/carbons)
even if they don't support this new XEP. For Responses this works but
for Actions it doesn't.
Marvin
On 4/21/20 1:18 PM, synd...@web.de wrote:
> Hi Marvin,
>
> I'll try to summarize the difference between Responses and Actions:
>
> A Response is supposed to be exactly equivalent to a "manual" text
> response, without any magic implied. That is, manually typing "yes" in a
> client that doesn't support Quick Response is 100% equivalent to
> selecting the "yes" Quick Response in a client that supports the XEP. An
> implication of the absence of "magic" here is, that Responses only apply
> to the most recently received message, because without magic there is no
> "reference" from the response to the original message.
>
> Actions are not compatible with clients that don't support Quick
> Response, as they require "understanding" the <action> element and
> responding with an <action-selected>. Because clients are free to
> generate unique ids here, the selection of an action is not limited to
> the last message, there is no problem relating the response to the
> original message. A "fallback" body is something that bots can choose to
> do anyway, by allowing to trigger the action via a plaintext response
> too (or comparable).
>
> Hope that clears it up,
> Syndace
>
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
