Conversation
Replace remote livekit-uniffi-xcframework dependency with a local path to the Rust SDK's UniFFI package output, enabling iteration on data track bindings without publishing releases. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Wire livekit-datatrack Rust managers into the Swift SDK's Room, SignalClient, and transport infrastructure. Data tracks provide frame-oriented, real-time data delivery with built-in DTP packetization and optional E2EE. Scaffolding (Phase 1): - Forward raw WebSocket bytes to Rust managers for signal routing - Create _data_track publisher/subscriber WebRTC data channels - Delegate bridges for signal requests, DTP packets, and track events - Manager lifecycle tied to Room connect/disconnect/reconnect - DataTrackDelegate protocol for track published/unpublished events Public API (Phase 2): - LocalParticipant.publishDataTrack(name:) and withDataTrack(name:body:) - LocalDataTrack.send(contentsOf:) for piping AsyncSequence to a track - AsyncPolling protocol with .values for DataTrackStream iteration - DataTrackFrame convenience extensions (.now, .latency) E2E Tests (Phase 3): - 8 tests mirroring Rust data_track_test.rs (publish/receive, large frames, duplicate name, unauthorized, state, timestamp, resubscribe, many tracks) - Test helper Room.waitForDataTrack(name:) for async track discovery Tests require livekit-server with enable_data_tracks and a tokio runtime fix in livekit-uniffi (pending). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Forward serialized protobuf bytes after parsing (not raw WebSocket bytes) so JSON-encoded messages from the server are also forwarded to Rust data track managers - Register DataTrackWatcher before publishing to avoid missing the initial ParticipantUpdate event - Use AsyncStream-based watcher for reliable async track discovery - Simplify resubscribe test to 2 iterations with delay Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Upstream livekit-uniffi replaced the generic `handleSignalResponse` with specific per-message handlers: - handleSfuRequestResponse (for RequestResponse) - handleSfuPublishResponse (for PublishDataTrackResponse) - handleSfuParticipantUpdate (for ParticipantUpdate) - handleSubscriberHandles (for DataTrackSubscriberHandles) Each handler returns UnsupportedType for messages it doesn't handle, so the simplest integration is to call all four with the raw bytes and let them filter internally. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.