feat(send_queue): Implement sending of MSC4274 galleries#4977
feat(send_queue): Implement sending of MSC4274 galleries#4977bnjbvr merged 25 commits intomatrix-org:mainfrom
Conversation
Signed-off-by: Johannes Marbach <n0-0ne+github@mailbox.org>
ba8aa4b to
0c3161b
Compare
| let info = assign!(info.map(ImageInfo::from).unwrap_or_default(), { | ||
| mimetype: Some(content_type.as_ref().to_owned()), | ||
| thumbnail_source, | ||
| thumbnail_info | ||
| }); | ||
| let content = assign!(ImageMessageEventContent::new(body, source), { | ||
| info: Some(Box::new(info)), | ||
| formatted: formatted_caption, | ||
| filename | ||
| }); |
There was a problem hiding this comment.
These blocks could maybe share the logic with make_attachment_type by extracting a function to create the content for each mime-type? I wasn't sure if it's really worth it because it might not be shorter due to the number of arguments on the call.
There was a problem hiding this comment.
Some form of code sharing would be nice, since it's a direct copy-pasto. I think a local macro (defined with macro_rules!) that contains the entire match would be nice here: the only thing that changes is the GalleryItemType vs MessageType, if I'm following correctly?
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4977 +/- ##
==========================================
+ Coverage 85.80% 85.81% +0.01%
==========================================
Files 332 332
Lines 36195 36211 +16
==========================================
+ Hits 31056 31076 +20
+ Misses 5139 5135 -4 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
I'm mindful that it's probably just a matter of lack of time but if there's anything I can do to simplify reviewing this PR, I'd be happy to follow any suggestions. |
|
Sorry about the long review time. I'll take a look this week, but indeed one large commit with that many changes is a bit overwhelming and hard to review. For PRs that large, in general, in the core team, we tend to do some synchronous video meeting with screen sharing, where the author explains the changes in real-time, giving some kind of "map" of the changes (where to start reading from, where to continue, etc.). If there's any chance you can do any of this in written form, that'd be great, but it is not mandatory :) One early comment, though:
I think this could be named |
No worries at all. I'm really grateful to get input on this hefty change at all. ❤️ I have expanded the bullets in the PR description to describe the code path in some more detail. I hope this is helpful.
Good call. I have copied your comment into the diff and will address it together with any other feedback you might have later.
Yes, you're probably right. I will try to pay more attention to canonicalizing commits in future. |
bnjbvr
left a comment
There was a problem hiding this comment.
Looks great! The test is quite comprehensive, that's nice.
A first batch of comments; I think we might be able to reduce the code duplication with the existing send_attachment functionality in various places, so let's try it out. If it turns out to be more trouble (e.g. require doing too much data/parameters shuffling, etc.), in some places, please don't hesitate to not do it.
I'd like to take another look after that, but it looks like this is on the right track. Thanks!
|
Thanks a ton for the review. 🙏 I've addressed most comment but will have to return to this next week for the refactoring of |
|
Ok, I think I've addressed everything now. |
bnjbvr
left a comment
There was a problem hiding this comment.
Thanks, looking great! I didn't expect some of the refactorings to happen that cleanly, that's super nice; thanks for making separate commits for those, that really helped.
What a journey! A few more stylistics comments, and I think we can merge this then 🥳
| match itemtype { | ||
| GalleryItemType::Audio(event) => match sent.get(&event.source.unique_key()) { |
There was a problem hiding this comment.
Can we invert the position of the match sent.get(...) and match itemtype? Then, we don't need to repeat it in each match arm.
There was a problem hiding this comment.
Hm, I think this doesn't work because event used in the inner match is only set through the outer match? We could maybe add an fn source(&self): Option<MediaSource> on GalleryItemType. That would probably have to go into Ruma though?
|
Thanks a bunch for getting this through the finish line 🥳 Excited to see it in action soon! |
This was broken out of #4838 and is a step towards implementing matrix-org/matrix-spec-proposals#4274. Building upon #4977, a new method `Timeline::send_gallery` in matrix-sdk-ui for sending galleries. - [x] Public API changes documented in changelogs (optional) --------- Signed-off-by: Johannes Marbach <n0-0ne+github@mailbox.org>
This was broken out of #4838 and is a step towards implementing MSC4274.
RoomSendQueue::send_gallerywhich is a generalization ofRoomSendQueue::send_attachment.send_gallerytakes as input parameters aGalleryConfig(containing info about the gallery itself, such as its caption) and a vector ofGalleryItemInfos (containing info about each image / file / etc. in the gallery).send_gallerycreates the gallery event content viaRoom:make_message_eventwhich was renamed frommake_attachment_eventto reflect the fact that it creates generalmsgtypeevents now.send_gallerymaps the passed item infos intoGalleryItemQueueInfos. This additional struct allows grouping all the metadata for a single gallery item together.send_galleryinvokesQueueStorage::push_gallerywhich is a generalization ofQueueStorage::push_media.send_gallerypushes upload requests for the media and thumbnails to the queue in a "daisy chain" manner. The first thumbnail (or media if no thumbnail exists) is pushed as aQueuedRequestKind::MediaUpload. The remaining thumbnails and media are pushed asDependentQueuedRequestKind::UploadFileOrThumbnails while chaining each request to the previous one.DependentQueuedRequestKind::FinishGalleryis pushed to finalize the gallery upload (analogous to the existingFinishUploadfor single media uploads).FinishGalleryrequest is handled inQueueStorage::handle_dependent_finish_gallery_uploadwhich was modeled afterhandle_dependent_finish_upload.AccumulatedSentMediaInfo, a hash map is used.update_gallery_event_after_uploadand a new methodRoom::make_gallery_item_typeThis is relatively large, unfortunately, but including everything needed to actually send the event made it possible to also add a test for it. It would be nice if the amount of new code could be reduced but I'm struggling a bit to find ways to integrate galleries with the existing media uploads further.