Conversation
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
RPCManager: bridge object for managing default and custom RPC calls bridge_rpc examples RPCManager tests
…rackActionFn action input an Enum
| /// Audio/video tracks support mute, unmute, and release. Data tracks | ||
| /// only support release (they have no mute/unmute); a mute request on | ||
| /// a data track is treated as release, and unmute returns an error. | ||
| namespace track_control { |
There was a problem hiding this comment.
same questions to the nested namesapces, what is the general design for the whole sdk ?
In case we are going with a nested namespace approach, I'd love to hear the benefits or considerations there.
There was a problem hiding this comment.
session_manager namespace was an oversight, that has been removed. In general i have tended to use namespaces for convenient grouping of variables. The design here was to put all RPC related constants in their own NS for organization purposes this way if we need to update the track control functionality it should be well confined and we know it wont conflict with other "built in" RPC calls
| } // namespace test | ||
|
|
||
| /** | ||
| * Handle to a published local audio track. | ||
| * | ||
| * Created via LiveKitBridge::createAudioTrack(). The bridge retains a | ||
| * Created via SessionManager::createAudioTrack(). The manager retains a | ||
| * reference to every track it creates and will automatically release all | ||
| * tracks when disconnect() is called. To unpublish a track mid-session, |
There was a problem hiding this comment.
That was one of my TODOs that if we should add a disconnect() function in the room.h.
The reason why I didn't do it was that the API does not exist in other SDKs like python, but I do see some benefits of a disconnect() function that auto release all published tracks.
There was a problem hiding this comment.
IMO this sort of handling should be done by the SDK since the track is tied to the room. IOW if the room is disconnected, the track is no longer valid. Users can of course delete the tracks themselves without disconnecting the room, but the "auto-cleanup" should be done by us when possible
|
|
||
| #include "lk_log.h" | ||
| #include "livekit/livekit.h" | ||
| #include "lk_log.h" |
There was a problem hiding this comment.
why it need to include lk_log.h ? shouldn't it be included inside the livekit/livekit.h ?
There was a problem hiding this comment.
I was originally intentding to design around users needing to compile against speedlog (in the case of custom user sinks). However, this may have been a bit of an overdesign. I updated lk_log.h to be a public header and included it in livekit.h.
8a60a99 to
89ffdc5
Compare
Overview
LivekitBridge -> SessionManager
SessionManager::getRoom()Building
SessionManager compiles with the base sdk as its own lib
Examples
All simply_* tests have been moved to
examples/base_sdkto clearly distinguish between base sdk vs expected dev workflow.added example to use the base sdk via
SessionManager::getRoom()NOTE
this includes the RpcController changes here