[Task] Hypothetically implementing parsing the `m.bot.command` mixin from MSC4332

[Gnuxie]

matrix-org/matrix-spec-proposals#4332

Modifying the MatrixInterfaceCommandDispatcher interface

• Edit the MatrixInterfaceCommandDispatcher interface (https://github.com/the-draupnir-project/interface-manager/blob/9c4745bb06841c436089ad0a2afb0c399f26e12b/src/MatrixInterfaceAdaptor/MatrixInterfaceCommandDispatcher.ts#L24-L34).
  • handleCommandMessageEvent would need to be renamed to handleMessageBodyCommand, but its arguments would be the same
  • Add a method called handleMessageMixinCommandwhich accepts the m.bot.command mixin.

Implementing the MatrixInterfaceCommandDispatcher['handleMessageMixinCommand'] method

Option 1: Substituting the arguments into a string.

You could simply substitute each argument into the string and then call handleMessageBodyCommand instead.

Option 2: Building a presentation argument string from the command ID

⚠️ this is a badly formed stream of thought

It may be possible instead to edit the CommandTable to automatically produce and intern command by their ID as designated in the MSC. But this is dirty and adds implementation detail from the MSC to the interface-manager abstraction. Why does the MSC not just use the designator parts as the command ID?

In any case if somehow this was made possible:

The command would be located from the command table by the ID in syntax (probably by modifying the command dispatcher abstraction or by parsing the designator parts from the command ID and using that instead).

Trying to use each parameter description name is used to find a variable in the mixin and place it into the stream, and then parsing the command from that stream would lead to a duplication of error tracking information, as interface-manager handles unexpected argument errors from parsing commands from the stream itself. So the only real option here would be to lazily parse the mixin with a custom PresentationArgumentStream specific to the m.bot.command mixin, and feeding that to the existing code that produces CompleteCommand's.

[Gnuxie]

All of option 2 would need to be implemented by making a presentation argument stream that would need to first read the designator parts from syntax to itself locate a command from a command table. And then use that command to produce the next arguments in the next order or signal the appropriate errors. It's not good

[Gnuxie]

I just don't think you can convert the mixin into a presentation argument stream and nor is it appropriate to do so. Instead we need to parse directly from the mixin a CompleteCommand or PartialCommand or an error about there not being enough or invalid arguments. So there would need to be a third option to encapsulate that. Fortunatley this would only require duplicating the effort in StandardMatrixInterfaceAdaptor's parseAndInvoke and we could call invoke.

[Gnuxie]

And we don't really need to do any of this if the client is providing a text representation of the argument anyways.

[Gnuxie]

And what about when the ban command requires a --no-confirm keyword? misery.