Conversation
stephen-derosa
force-pushed
the
sderosa/bridge-rpc
branch
2 times, most recently
from
e38dd58 to
3237ad6
Compare
|
I think we are on the right track. some more questions |
| * @param handler Callback invoked on each incoming invocation. | ||
| * @return true if the RPC method was registered successfully. | ||
| */ | ||
| bool registerRpcMethod(const std::string &method_name, |
There was a problem hiding this comment.
RpcMethod is pretty low level, I wonder if we should make a remote controller, and we will setup a remoteControlInternal method as the communication channel for the remote control
There was a problem hiding this comment.
im not sure i understand the need to break this into another layer. My intention here was to have a single object (currently RPCManager) which does all the interfacing with the local participant required to register/make/receive RPC calls. I wanted to keep the function of registerRpcMethod here the same as it is in the local participant for clarity.
There was a problem hiding this comment.
who is going to call this registerRpcMethod() ? like developers ? or it will be called by your RpcController / RpcManager ?
There was a problem hiding this comment.
a developer in their application would call: livekit_bridge->registerRpcMethod("my-awesome-rpc", awesome_rpc_handle) which simply wraps around the RpcController
stephen-derosa
force-pushed
the
sderosa/bridge-rpc
branch
from
b6cfa19 to
967a37b
Compare
| * @param handler Callback invoked on each incoming invocation. | ||
| * @return true if the RPC method was registered successfully. | ||
| */ | ||
| bool registerRpcMethod(const std::string &method_name, |
There was a problem hiding this comment.
who is going to call this registerRpcMethod() ? like developers ? or it will be called by your RpcController / RpcManager ?
| const std::shared_ptr<livekit::Track> &track, | ||
| VideoFrameCallback cb); | ||
|
|
||
| /// Execute a track action (mute/unmute/release) by track name. |
There was a problem hiding this comment.
just found that you are expecting the users to call release for the tracks explicitly ?
aren't tracks managed ?
There was a problem hiding this comment.
users have the option to release tracks in the case they want to release a track before disconnecting. But in the case a disconnect happens, the track will be release by the manager.
There was a problem hiding this comment.
that being said, these RPC calls are to enable a remote participant to request mute/unmute of another remote participant.
| * @param track_name Name of the track to mute. | ||
| * @return true if the track was muted successfully. | ||
| */ | ||
| bool requestRemoteTrackMute(const std::string &destination_identity, |
There was a problem hiding this comment.
These APIs are very concerning and can be very confusing.
What if the remote participant is not a livektiBridge (or SessionManager after the rename )?
How do you make sure these actions are backward compatitable ?
There was a problem hiding this comment.
These built in RPC calls only work from session manager to session manager, since the RpcController belongs to the session manager. Of course users can register their own remote track mute/unmute RPC methods!
xianshijing-lk
left a comment
xianshijing-lk
left a comment
There was a problem hiding this comment.
lets keep the livekit_bridge naming then
RPCManager: bridge object for managing default and custom RPC calls bridge_rpc examples RPCManager tests requestTrackMute/Unmute -> requestRemoteTrackMute/Unmute . Make the trackActionFn action input an Enum add spdlog to docker and github actions
stephen-derosa
force-pushed
the
sderosa/bridge-rpc
branch
from
98c595e to
22498a1
Compare
2 participants
Overview
RPC Controller for handling built in RPC calls and user registered RPC calls.
Built in RPC calls
Examples
examples/bridge_mute_unmute/
examples/bridge_rpc/
Testing