Iterate on Protocol Module interface design and how Feature Modules interact with them

[ZeroKnight]

Initial Thoughts (2020)

Given the state of flux during the development of the Discord implementation and command interface, the Context interface and the IRC protocol implementation weren't updated as I hacked away proof of concept code in the Discord implementation. These need to be brought up to parity with these trailblazed additions.

Over time porting feature modules, there have been multiple cases where protocol-specific behavior was desired. Currently, this is implemented rather hackishly by just directly importing discord for example. There should be some kind of "intended" way for feature modules to do this. Similarly, Context should include optional interfaces for actions like searching channel message history (if the protocol supports it) and searching user/online lists, etc.

Return from Hiatus and Recent Insight (2023-2024)

ABCs and ZeroBot-abstracted base objects

For other aspects, such as "servers" themselves, it would likely be a better strategy overall to rely on dependency injection and keep the abstract base very lean; there's bound to be too many fundamental differences between protocols to have much more than super fundamental concepts in common. The example in this video is what I'm thinking.

Work Done So Far

• [x] Protocols can signal feature support similar to LSP capabilities, IRC ISUPPORT, etc.
• [x] Expand and solidify Context interfaces
  • [x] Things that should be interface requirements are now (more things enforced via abstractmethod)
  • [x] Added common "requests" to the generalized Context interface (fetch users from channel, search channel history, construct a reply, etc.)
  • [x] Extra arguments can be passed to context message methods and can be opportunistically consumed by implementing protocols
• [x] Make the Discord protocol compliant with new interface specifications
• [x] Channel.is_dm allows Feature modules to alter their behavior around DMs accordingly
• [x] Various patterns for mentions are exposed to Feature modules via the Context
• [x] Generic entities now enforce having an ID property

[ZeroKnight]

💡 Idea: Could design/implement a "capabilities"-like system that both feature and protocol modules can design around. I imagine it working similar to IRC's ISUPPORT or LSP's "capabilities". As an example, I could have a capability for embeds that protocols can implement as part of an interface, but also report to feature modules that it supports upon registration. This would allow feature modules to switch up some logic on how to format their output based on the protocol they're sending to.

[ZeroKnight]

After briefly perusing the Matrix spec, there isn't a direct equivalent to Discord's embeds. There's also no other protocol that I can foresee implementing any time soon that does, so I don't think there's a point in abstracting this right now.

I can just allow (as I have been) feature modules to simply opt into using Discord embeds. I could potentially add a small utility interface to the Discord protocol module (or in ZeroBot.context) that allows feature modules to construct an arbitrary output with both a regular text and embed form, which can be passed as-is, with the embed output only being used when going to Discord.

[ZeroKnight]

Completed in commits db525f8df242...8a24e83dc499