On 4/21/20 5:58 PM, Marvin W wrote:
(inline)
On 4/21/20 4:51 PM, Tim Henkes wrote:
The question here is, why make a difference between "legacy" clients and
clients with support? Why hide that an action was performed from users
with supporting clients and show that an action was performed to users
of "legacy" clients?
Well, supporting clients can display the "action was performed"
information different from a normal message, just legacy clients can't.
For example the supporting client could change the design of the button
that represented the action to show that this button was pressed. Or the
message could be formatted differently. Or...
Ah I could've guessed that you also want supporting clients to do/print something. I
dislike that for the reasons I gave already, e.g. that for votes in MUCs this could
create a huge amount of useless spam on legacy clients. Also "change the design of
the button that represented the action" etc. is controlled by the supporting client,
while the fallback body is controlled by the bot. This is an inconsistency to this
solution that I also dislike. Without a fallback body or any other types of reactions to
actions, the output is consistently controlled by the bot itself. And the bot is the unit
that knows best which information to print at which point.
This mixes things up I think. Messages that are triggered by an action
are always visible as such, because they contain an <action-selected>
element. Messages that are triggered by a quick response are not meant
to be anyhow differentiable from manually types messages.
I as a client developer might want to display the fact that a message
was triggered through Quick Response or not. Right now I can only do
that as the sending client because the information is not preserved in
carbons/MAM. IMO every information that exists locally should also be
stored in MAM so that other devices can pick this information up.
I'd rather add "a client MUST NOT treat a quick response differently
than a normally typed response" to the protoXEP than send that
information out. It misses the point of Quick Responses being just quick
responses.
In your example: If there would be no way to see the "Merge MR!3", how
would I know if the merge request was merged because of my message or
that it just happened through the web UI?
Why do you want to know? In the example of a merge request it does not
matter at all, the action is just a quicker/more convenient way to
trigger the merge request in exactly the same way that would be possible
via the web interface. The bot could also just add "triggered by ..." to
its merge notification. Can you construct a scenario where this is
actually relevant?
For a merge request it is highly relevant who merged it. I don't know
any code management software that will not display that to you, except
if you put effort into hiding it.
Agreed. As it is so extremely relevant, every Git bot will also mention
in the merge notification who merged it. The nickname of the merging
person in the MUC is rather irrelevant, especially in anonymous MUCs,
while the Git name/email is much more relevant. Which actually
strengthens my opinion that automatically spamming the chat when an
action was performed is not helping. To repeat what I wrote in my last
mail, the bot has full control of the content of a hypothetical fallback
body. So whether the bot puts "I clicked merge" into the fallback body
or prints "marvin clicked merge" itself is zero difference, except that
the second also confirms that the bot has correctly registered your click.
Thing is, if the bot defines the body to print when an action is
selected, the bot can just as well just print that message itself when
the action is performed. Take the following two options:
*marvin selects action*
marvin> /Merge MR!3
gitbot> MR!3 merged
vs.
*marvin selects action*
gitbot> marvin triggered the merge of MR!3
I don't see how the first variant would be superior to the second, keep
in mind that in both cases the bot fully controls what is printed, in
the first variant by setting the "fallback" body and in the second
variant by printing it directly.
The second variant is superior if the reply from gitbot is not
instantaneous. Let's say, the reply takes 10 seconds, I'd like to know
that my message was send properly. And in a MUC I'd like others to see
that I already did perform the action, so they don't need to do it as well.
When starting a long-running operation the bot could print something to
indicate that, though I don't think that's necessary for something like
a 10 second merge.
Hehe true, simple polls could be handled with thumbs up or thumbs down
reactions, but polls with more options would require mapping emojis to
options etc. :D A poll bot could obviously offer more functionality,
like limiting the time for votes, printing cool summaries or even doing
stuff based on the result of the vote.
Couldn't a bot do time limit, summaries and anything else also when the
vote is based on reactions? And mapping to emojis is really straight
forward given that there are the keycap emojis (1️⃣). I know a vote bot
based on reactions exists for Slack.
I'm sorry I don't know what point you are trying to make with this, are
you saying that anything possible with actions can be done by mapping
emojis of reactions? I don't know if that's something I want to argue
about further.
You just can't use reactions if you want votes to be private, in which
case you also can't use this ProtoXEP (as everyone in the room can see
which actions are performed by whom) - except if you do the voting in
direct messages, in which case you can use reactions again.
Yeah private actions are on my list to think about should this get
accepted as an experimental XEP.
Quick Responses are restricted to the last received message with a MUST,
In that case, quick responses are effectively unusable in MUCs because
someone could just send a message before you and therefor make it
impossible for you to use a quick response.
Yes, use of quick responses in MUCs are probably rather limited. Which
comes from the fact that quick responses are just simple plaintext
messages that you could have typed manually. Even humans sometimes have
problems relating a response to the original message. A bot without help
of any ids is completely lost here. That's why the quick responses are
limited to the very last message.
Also, if there is no indication in the message that a message is a quick
reply, someone could maliciously use this XEP by having a response value
that isn't related to the label at all. This can even be used to lure
users into writing exactly the opposite (value="Yes", label="No"). So
for quick responses, we might want to disallow having a label different
from the value when in MUCs.
You are pleading for a fallback body, which would also be controlled by
the bot. When clicking "merge" the bot could make you print "merge
request rejected and closed" instead. Though I agree that the labels are
something to think about and should probably be removed. But if labels
are removed, that's another strong contra against fallback bodies.
Marvin
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
