Allow plugins to process user responses to their messages

Registered by ChrisD

Rather then only being able to respond to commands plugins should be able to perform stateful communication e.g.

endroid: What is your name?
user: Dave
endroid: Age?
user: 24

Currently this is difficult for plugins to achieve as they can only register to be notified of all messages, messages matching a reg exp or messages matching a command prefix.

To achieve stateful comms the following is proposed

 * on message_send a plugin can provide response and no_response callbacks to mark that message as requiring a response
 * endroid ensures only a single response_required message can be outstanding per 'sender' (person or room(?))
 * on receipt of a message endroid performs its usual processing upto (but not including) calling any unhandled callbacks.
    At this stage if there is an outstanding response_required message for that sender:
     * if the message was handled call the message's no_response callback
     * if the message was unhanded call the message's response callback with the message content as an argument.

Other considerations:
 * Timeout on resp_required messages if no message is received from that sender after a while (perhaps configurable by the plugin but with a minimum).
 * Could work in MUCs but might need to only consider messages with EnDroids's nick in them e.g. @EnDroid Dave, or be truly sender-specific (so EnDroid can sustain multiple conversations with different people at the same time in the same room).

Blueprint information

Series goal:
Milestone target:
Started by
Completed by

Related branches



Proposed and implemented that we check the other way round: per 'sender = person', a single response_required message can exist (any subsequent addition of a message replaces the previous ones, although calling send_chat with callbacks None in the usual way won't overwrite the previous callbacks). If a response_required message is outstanding, Endroid attempts to handle the next message using that response_required callback. If the callback fails, we consider it 'unhandled' and pass to normal plugin handling. The response_required callback is then forgotten, whether or not it successfully handled the response.

This is in an attempt to reduce end-user confusion: context-aware plugins are *only* aware of what immediately follows the message which set up a context. Otherwise we could have two plugins simultaneously attempting to get user input, which could be hard for the user to navigate. Moreover, if we envisage the following:

Endroid: Please type '3'.
User: help
Endroid: EnDroid at your service!
User: 3
Endroid: Thanks for the 3

This seems a bit less intuitive than:

Endroid: Please type '3'.
User: help
Endroid: EnDroid at your service!
User: 3
Endroid: I don't recognise that command.

(since the intervening command `help` might have printed out long and complicated stuff, which intuitively resets context in the mind of the user.)


Work Items

This blueprint contains Public information 
Everyone can see this information.


No subscribers.