-
Notifications
You must be signed in to change notification settings - Fork 253
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
sdk: implement MSC3489 live location sharing #3621
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3621 +/- ##
==========================================
- Coverage 84.25% 84.23% -0.03%
==========================================
Files 259 260 +1
Lines 26592 26648 +56
==========================================
+ Hits 22406 22446 +40
- Misses 4186 4202 +16 ☔ View full report in Codecov by Sentry. |
5785d01
to
33816d2
Compare
2a702bb
to
df93412
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the PR! supporting live location sharing in the SDK will be grand!
So, I appreciate the amount of code you've written here, and that it might be sufficient to have the basic feature working. However, I think the work here could be split (to make reviews faster) and layered in different ways:
- support for the base crate and SDK could go in a separate PR
- sending the beacon events themselves could happen in the SDK main crate too (I haven't seen any code for this, I think?)
- better handling of beacon events coming before their associated beacon info event could be another PR.
- then support for the timeline / FFI bindings
Each PR would also have tests at its own level, to make sure that it's behaving as intended. We're requiring tests for major functionality like this, otherwise it's too big a risk to discover later that it may be broken in subtle ways.
In fact, I think there's also potential for a more ergonomic, higher level API for beacons:
- provide a stream to listen to new live location shares (client wide)
- for each live location share, a stream to listen to new beacon events, and updates about the beacon info itself (stopped/redacted/etc.)
Then, the timeline could spawn a task, and provide UI updates based on both stream updates.
How does that sound?
user_id: OwnedUserId, | ||
) { | ||
let mut beacon_state = BeaconState::new(c, user_id.clone()); | ||
if let Flow::Remote { event_id, .. } = self.ctx.flow.clone() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: use &self.ctx.flow
instead of cloning
}); | ||
|
||
if !found { | ||
warn!("Did not find beacon_info event in timeline items. Adding to pending list"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
warn
should be kept for non-fatal errors.
warn!("Did not find beacon_info event in timeline items. Adding to pending list"); | |
debug!("Did not find beacon_info event in timeline items. Adding to pending list"); |
let Some(location) = beacon_state.last_location() else { | ||
return TimelineItemContentKind::FailedToParseMessageLike { | ||
event_type: "org.matrix.msc3672.beacon".to_string(), | ||
error: "Could not find beacon last location content".to_string(), | ||
}; | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the last location was not set, then I think the TimelineItemContent should not exist in the first place.
pub async fn send_user_location_beacon( | ||
self: Arc<Self>, | ||
geo_uri: String, | ||
) -> Result<(), ClientError> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's way too much logic in this function; it should not live at the FFI layer, otherwise it's ~impossible to test.
//! This module handles rendering of MSC3489 live location sharing in the | ||
//! timeline. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think having this in the timeline is the proper cutting point. Instead, this would be more useful to have at the SDK layer, and maybe even with a slightly different API.
Also, we'd need some way to implement redaction of all the beacon events related to a beacon info event, as indicated by the MSC. |
@bnjbvr Thanks for taking time to provide such detailed feedback! I agree with all your points and can work on splitting this up into simpler PRs and layer it as described. The stream API is good approach and would make life a lot easier 😃 |
@bnjbvr Do you have an example of streams being used in the codebase? This should help me get some more direction once I get to this. |
You can look for functions which names end up with |
@bnjbvr I'm working on handling beacon events and associating them with their beacon info events, as mentioned in
Any guidance on where to place this logic specifically where I should be grabbing the beacon events from? |
Sweet! I suppose that could go in a subsequent step, when it's time to display/render the beacons themselves, in the timeline. As far as I understand, the support should be pretty minimal/straightforward in the SDK, and ordering is only important as soon as you want to display something, right? Happy to chat about this in the Matrix SDK dev room, if needs be. |
Closing, assuming this is superseded by #4025. Please reopen if that's not the case. |
Add support for MSC3489 live location sharing. Requesting an initial review to clarify some technical questions and help get this over the finish line.
Building on this Ruma PR
Signed-off-by: