dronefly
dronefly copied to clipboard
last: Rewrite as interactions stored in config
Instead of plowing through channel histories to search for links & commands, record bot interactions in a config-backed history which can then be retrieved by the user in a less wordy fashion:
- replacing grepping the history for bot commands:
- see current
,last obs
recently added corner case: PAT_OBS_LINK matchesobs #
- I'm unhappy with the sloppiness of the pattern match here
- see current
- replacing grepping the history for links:
- currently looks all over the place (user commands, the bot responses, digging into the embeds! ugh.)
- introducing monitoring of messages for interesting things, e.g.
- the long planned
on_message
hook to notice when links are pasted in channel including:- user profile links
- observation links
- taxon links
- and then dispatching to the bot the job of previewing these as needed
- the long planned
- and also introducing editing of auto-previewed messages to insert the iNat-specific summaries at the top
- clearing up the mess that is
,link
vs.,obs
(confusing to have two commands doing the same thing! only doing this because,link
nicely formats the message in a single embed) - and introducing reasonable default behaviours for certain command syntaxes that either are invalid or else just show the help, e.g.
-
[p]obs
-> should show most recent observation- replacement for
[p]last obs
- replacement for
-
[p]map
-> should show the map for the most recent observation or taxon- replacement for
[p]last obs taxon
and[p]last taxon
. we don't need both, as the most recent bot interaction of either kind should take precedence.
- replacement for
-
[p]taxon
-> should show taxon for most recent observation -
[p]family
-> should show family for most recent observation or taxon
-
https://github.com/synrg/dronefly/issues/37 is a good place to start for the on_message
hook part of this problem (i.e. simply reacting to messages & previewing).
Not sure if config-backed is even needed most of the time. Just remembering what happened since the bot joined is probably good enough for most of the "related info traversal" needs.
The only time not being aware of channel history becomes annoying is when the bot has to restart in the middle of a bot interaction. While that might happen frequently with the development bot, to be kind to my users, production bot restarts should really be kept to a minimum. It would certainly help reduce complexity if I pared this back to only be a shallow history of recently remembered interactions kept in-memory per channel.
So consider just a simple in-memory limited length collections.deque for each "thing" to remember: 'query for a taxon', 'query for an observation', 'navigation up or down taxonomy tree from taxon-or-observation'. In particular, 'query for a taxon', and 'taxon navigation' should be remembered as separate things so that 'show the family of the last taxon query' isn't misunderstood to be 'show the family of last taxon navigated to' (which might not even be possible if, e.g. they navigated to the superfamily).
In #141 we are working towards having recent interactions with taxon
and tab
displays (via reaction buttons) cause those displays to be cached for a time. We could dispense with even having to parse them if we started out by placing the embeds in the cache as soon as they are created. Then last
has even less work to do if the most recent message of the requested type is already cached. Revisit this issue once that issue is complete.