Today RM_Call allows executing any commands you want, even commands that make no sense to call inside RM_Call like MULTI or BLPOP. Though It is true that modules are not like LUA and should be smarter not to do such things, sometimes you want to execute a command base on client input (for example if you create a module that provides a new scripting language like javascript or python). So if a module wants to know if a command can or can not be executed inside RM_Call, the module needs to perform command info, get the command flags, and to decide whether or not to allow it.

Though solvable, I suggest a better API that allows modules to get a command flags. The new API will expose a new RedisModule API function int RM_GetCommandFlag(RedisModuleString **argv, int argc). The API will return the command flags and the module will be able to check for the existence or unexistence of different flags to decide what to do (for example if the module does not want to allow write commands he can verify that the readonly flag is on). The suggested API gets the entire command and not just the command name because after a discussion with @oranagra I understood that in the future, subcommand might influence the command flag, so we might want to pass the entire command so Redis can be smarter about the returned value. In addition, notice that the flags are returned as int (and not as char*) this contradicts the way the flags pass on RM_CreateCommand (today Redis get them as cha*). I think return int is better so the module will not have to start parsing and comparing strings. I also think we should introduce a new CreateCommand API that allows sending the flags as int (and maybe eventually deprecates the existing RM_CreateCommand).

Of course, everything here is just a suggestion, will be happy to hear your thoughts and ideas.

@oranagra @yossigo @itamarhaber @guybe7