1 Jul
2024
1 Jul
'24
8:32 p.m.
Hi,
thanks for the clarifications Marvin, you explained my intentions very
well :)
The use-case I had in mind for <response> is "memberbot asks me 20
yes/no questions in a row, would be cool if I could just click on yes or
no buttons". This is purely assistive and requires no feature detection;
the usual input is not blocked and you could still type out "yes" or
"no" manually. Selecting one of the quick responses would just send the
message as if you'd typed it out.
A use-case for <action> is for example a Git bot that sends
notifications about newly opened issues/pull requests and attaches
actions to close/merge/etc. Those actions would stay attached to the
message, so you could scroll up to older messages and trigger an
attached action to e.g. close some issue.
Is the original Author still around?
Yes, I'm sorry for not showing this XEP more love after it was accepted
as experimental, but I'm ready to pick up work on it again.
What is confusing to me IMO is that this is one XEP,
where it clearly
has two distinguished functionalities that could easily be
completely
independent XEPs.
I agree, it developed into two separate, barely related functionalities
that could be split.
Tim
On 01.07.24 09:54, Marvin W wrote:
Hi Philipp,
I'm not the author, but I feel I can answer most of the questions.
On Sat, 2024-06-29 at 13:25 +0000, Philipp Hörist wrote:
Im not getting the difference between
<response> and <action>.
And the XEP makes no attempt to describe it.
Quick responses are regular messages
with a <body>. They are only
available as a direct response to the very last message in a
conversation. If the receiving client does not support quick responses,
the user can just manually type in the response and quick responses
sent from other devices are displayed as usual messages in the same way
as they're displayed on devices that do support it.
In a user interface, I'd expect the following:
- The buttons for quick responses only show as long as there was no
message since the message they respond on (see rule 3 in business
rules). They might be "attached" to the message or the chat input
field.
- Quick response availability does not prevent regular chat input.
- Selecting a quick response button will behave largely the same as if
the user typed the message of the quick response value in the chat
input and sends it.
- The quick response will be displayed as a regular message in the chat
history.
Actions, in contrast, are not using a <body>. They can be sent at any
later point as they are merely announced via the message, but not
necessarily related to it. Receiving clients that don't support actions
can't send them and don't see if other clients sent them.
In a user interface I'd expect the following:
- The buttons for actions show infinitely (or, client-specific, after a
timeout - this sounds like something that could also be announced with
the <action>). They should be attached to the message itself and remain
visible even after being selected.
- Action availability does not prevent regular chat input.
- Selecting an action will likely display somehow that the action was
performed, but doesn't prevent any attempt to perform it again or any
other action announced on the same message. (the ability to modify this
behavior might be worth adding to the spec)
- The action will not be displayed as a regular message in the chat.
The bot on the other end will likely send a follow up message to
indicate that the action was performed.
Now for <actions>, the id attribute is
under specified, it seems
essential to the whole thing working at all.
Should this be a globally unique ID? Or at least unique per remote
JID?
The business rules have some section on this that IMO explain that very
well:
Sending clients MUST keep in mind that they have
to choose/generate
ids for each <action> accordingly, if they need to
differentiate
between messages.
In other terms, if an action depends on the message it was selected
from, the id of the action should just include the id of such message.
But as the example with merge shows, the id of the message might just
be entirely irrelevant: The action with id merge-32643 might instruct
the bot to merge the merge request 32642 and it doesn't matter if this
action was sent as an action from the message that announced that the
merge request with opened or from the message that announced it was
reviewed. The id of the action is self-descriptive for the action, if
it depends on the message, then to be self-descriptive, the id must
reference the message.
What is confusing to me IMO is that this is one XEP, where it clearly
has two distinguished functionalities that could easily be completely
independent XEPs.
Marvin
_______________________________________________
Standards mailing list -- standards(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org