You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to implement #64, the bot needs to be able to record the ids of messages it sends, tagged with some kind of metadata related to its content/purpose.
Right now, most messages the bot sends are done so implicitly (by having module dispatchers fill data into a MessageBuilder and allowing the MultiBot dispatcher send it out through ntelebot). This means that, for example, the events module can't just capture the return value from MessageBuilder.reply and store the id somewhere internally.
One possibility would be to have MultiBot record all messages it sends, and make them available via ctx. events could then look backward through the record to find something in the given chat that looked like something it sent and perform #64's update logic on it. This could go a step further and have MultiBot actually keep track of which module ended up capturing the update and tag it by name in the record (and/or keep messages separated by module), so events would just have to look for its most-recent message in the given chat.
A slight variation would be to have modules explicitly mark messages (via MessageBuilder) that they want a record of, maybe setting msg.record = __name__ or msg.tags.add(__name__). Only so-tagged messages would then be recorded by MultiBot (or directly by MessageBuilder).
The text was updated successfully, but these errors were encountered:
nmlorg
added
the
cleanup
Code changes that improve maintainability without changing behavior
label
Jul 22, 2019
In order to implement #64, the bot needs to be able to record the
id
s of messages it sends, tagged with some kind of metadata related to its content/purpose.Right now, most messages the bot sends are done so implicitly (by having module dispatchers fill data into a MessageBuilder and allowing the MultiBot dispatcher send it out through ntelebot). This means that, for example, the
events
module can't just capture the return value fromMessageBuilder.reply
and store theid
somewhere internally.One possibility would be to have MultiBot record all messages it sends, and make them available via
ctx
.events
could then look backward through the record to find something in the given chat that looked like something it sent and perform #64's update logic on it. This could go a step further and have MultiBot actually keep track of which module ended up capturing the update and tag it by name in the record (and/or keep messages separated by module), soevents
would just have to look for its most-recent message in the given chat.A slight variation would be to have modules explicitly mark messages (via MessageBuilder) that they want a record of, maybe setting
msg.record = __name__
ormsg.tags.add(__name__)
. Only so-tagged messages would then be recorded by MultiBot (or directly by MessageBuilder).The text was updated successfully, but these errors were encountered: