On 4/21/20 3:39 PM, Marvin W wrote:
(inline)
On 4/21/20 2:32 PM, synd...@web.de wrote:
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.
The message would only be visible to legacy clients. Clients supporting
Quick Responses can detect that the message is indeed a Response/Action.
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?
It probably is a good idea to add some sort tag to messages that are a
Response so that it is visible the body was created through button press
and not through text input.
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.
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?
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.
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".
Interesting example, because it sounds more like something typically
done using reactions and there was a lot of discussion if reactions
should have fallback or not already. IMO reactions shouldn't have a
fallback body, so if actions are used similarly to reactions, they also
shouldn't have a fallback body. However in that case you should probably
just use reactions ;)
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.
You also mentioned MUCs, however the current ProtoXEP does not specify
any MUC behavior. I also don't think the proposed protocol can be used
in MUCs out of the box and requires actual changes
- How do you use quick responses when there is multiple people writing
messages that allow for quick responses?
Quick Responses are restricted to the last received message with a MUST,
because there is no way to relate a response to the original message. I
think this question is rather general actually: how to handle if
multiple bots ask questions that require plaintext responses? Keep in
mind that quick responses are just plaintext messages you could've
written manually, no magic. So this problem isn't actually a problem of
quick responses, but the general problem of how to do questions/answers
in MUCs.
- How do I know that a certain action is actually intended for a
specific bot in a MUC?
That's missing, right. Could be as easy as referencing the MUC-jid of
the bot in the <action-selected> element. I'll think about it.
As there has been some discussion regarding the use of Forms instead:
Forms cannot be used to do what is proposed as Responses in the
ProtoXEP, but they can already do what is proposed as Actions. Maybe
just focus on the one thing in this XEP and not put two mostly
independent things in one XEP?
Splitting this into two protoXEPs has been proposed by Dave and I also
feel like it should be split. The two features are pretty much
independent, even though they solve "similar" issues that probably both
come up when implementing bots.
Regarding forms there also was some input by Dave. If actions can be
done with forms without much struggle I'll change actions to use forms
instead. Though I think that actions as they are now are so extremely
simple that it might not be worth to pull in forms. We'll see though,
I'm open to the possibility.
Marvin
_______________________________________________
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
_______________________________________________
