I'd like to implement some custom publish and call options in the router.
Specifically, I'd like to make a module which forwards certain publish and call messages from one realm (a source) to another (a destination), and in the source realm, it can take the options for the destination realm into an option for the message.
To accomplish this, I have two internal clients - one in the source realm, and one in the destination realm - and I forward to the destination on a message eligible for the source internal client. So far, so good... except the options of the publish/call in the source are not available in subscribe/register callbacks.
Trying to add it to the details took me down to needing a custom subscription group for the publish messages, which in turn requires a custom broker. And similarly, implementing this for a call requires a custom dealer. This is however not possible currently.
I've currently implemented this with a custom kwArg name instead that I know my application won't use, but I was hoping to generalize this enough that I can use fully arbitrary kwArgs.
I guess I could instead implement two RPC calls in the source realm - one for publish to the destination and another for calls to the destination. While that would work too, and would allow any kwArgs, it would also be less ergonomic, as the original idea is that only the router would care that the known topics/procedures are special. The client in the source realm should publish and call as normal, not necessarily caring about the destination realm.
EDIT: On second thought, for my use case, RPC calls would work fine. The only downside is that because both internal clients are trusted, this means anyone in the source realm can publish/call anything in the destination realm. Since there's no pattern matching of RPC calls yet (see #356 ), there's no way to add any authorization rules for the source realms... But in my case, the source realm is trusted enough, as it is an admin panel realm. If an unauthorized user has gained access to the realm, that alone is a bigger problem than ACL of RPC calls.
Still though, brokers and dealers should ideally be extendable or replaceable.
I'd like to implement some custom publish and call options in the router.
Specifically, I'd like to make a module which forwards certain publish and call messages from one realm (a source) to another (a destination), and in the source realm, it can take the options for the destination realm into an option for the message.
To accomplish this, I have two internal clients - one in the source realm, and one in the destination realm - and I forward to the destination on a message eligible for the source internal client. So far, so good... except the options of the publish/call in the source are not available in subscribe/register callbacks.
Trying to add it to the details took me down to needing a custom subscription group for the publish messages, which in turn requires a custom broker. And similarly, implementing this for a call requires a custom dealer. This is however not possible currently.
I've currently implemented this with a custom kwArg name instead that I know my application won't use, but I was hoping to generalize this enough that I can use fully arbitrary kwArgs.
I guess I could instead implement two RPC calls in the source realm - one for publish to the destination and another for calls to the destination. While that would work too, and would allow any kwArgs, it would also be less ergonomic, as the original idea is that only the router would care that the known topics/procedures are special. The client in the source realm should publish and call as normal, not necessarily caring about the destination realm.
EDIT: On second thought, for my use case, RPC calls would work fine. The only downside is that because both internal clients are trusted, this means anyone in the source realm can publish/call anything in the destination realm. Since there's no pattern matching of RPC calls yet (see #356 ), there's no way to add any authorization rules for the source realms... But in my case, the source realm is trusted enough, as it is an admin panel realm. If an unauthorized user has gained access to the realm, that alone is a bigger problem than ACL of RPC calls.
Still though, brokers and dealers should ideally be extendable or replaceable.