Hey,

Today RedisModule allows low level operation on redis data type such as set string and push/pop from lists. As modules are able to create new datatypes, I find it helpful if modules could also expose their own api to allow other modules to use those new datatypes. I thought maybe its possible to add the 'moduleRegisterApi' function to the RedisModuleAPI, this way modules will be able to use it to register their api functions and other modules will be able to use 'RedisModule_GetApi' to get api function of other modules.

Thoughts?

Comment From: itamarhaber

Hello @MeirShpilraien

Today we have the ability to call a module's commands from another module with RM_Call. IIUC, this FR is about being able to call a module's API from another module directly, without going through the fake client, correct?

If so, please take a minute to explain to me why you'll "find it helpful".

Comment From: MeirShpilraien

Couple of reasons: 1. It will be faster (no need to perform lookup on the command, no need to parse the argument list ...) 2. It will be easier for the caller (no need to parse the response) 3. Sometimes you want to expose abilities which are not actually a commands like add extensions (In redisearch for example you might want to allow other modules to add query expenders) 4. RM_Call are not working with blocking commands, in this case for example you might want to expose an api that gets callback.

Comment From: itamarhaber

I'm not a real system developer, so I have no problem asking stupid questions :)

  1. Granted
  2. I see that as a part of 1, and as for the easiness maybe something like rmutil can have a complex macro to handle the back and forth.
  3. That's perhaps the real added value - I was thinking of the recently added internal dictionary data type for modules in that context. While RediSearch can certainly benefit from that, it already has its own modules mechanism and most modules aren't as robust as it anyway.
  4. Right, but that could be "fixed" with a variant such as RM_CallBlocking perhaps.

My main worry besides the complexity (?) of implementing this, is that we'll be increasing the impact of inter-module dependencies (currently limited to working via RM_Call or a client e.g. hiredis) by orders of magnitude as well.

That said, I'm a sucker for the shiny new stuff. I'm sure that @yossigo has a lot to say about this... I seem to remember that he has a hack up his sleeve that allows you to do something like that.

Comment From: yossigo

@itamarhaber I agree that fixing the limitations that prevents RM_Call() on a blocking command is the first step. I can't think of any functional benefit of an API for direct function calls between modules, which cannot be expressed through exposed Redis commands.

I do see other benefits: 1) Performance optimizations (it goes way beyond args parsing) 2) The ability to expose cross-module functions without necessarily exposing them to end users as Redis commands.

I think ideally this API can be some module extension (rmutil style) and not in the core API. Because modules are dlopen()'d RTLD_LOCAL (for a good reason) it's not a trivial task but an elegant way of doing that may nevertheless be lurking waiting to be found. I'll try to come up with a suggestion.

Comment From: yossigo

Closing as this was already implemented by 27f6e9bb9b (and a few others).