timeline: factor out inner part of [Sync]TimelineEvent
#4082
Conversation
This file contains 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
I found it hard to understand what these two structs were for, so let's start by giving them some documentation.
I'm going to change the internal structure of `SyncTimelineEvent`, and since it implements `Deserialize`, we need to not break it. Let's add a test for the current format.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4082 +/- ##
==========================================
+ Coverage 84.66% 84.68% +0.01%
==========================================
Files 269 269
Lines 28694 28749 +55
==========================================
+ Hits 24294 24346 +52
- Misses 4400 4403 +3 ☔ View full report in Codecov by Sentry. |
bnjbvr
requested changes
Oct 7, 2024
richvdh
force-pushed
the
rav/timeline_event_inner
branch
7 times, most recently
from
feca893 to
ba762a8
Compare
|
@bnjbvr please take another look? |
bnjbvr
approved these changes
Oct 9, 2024
There was a problem hiding this comment.
Thanks, LGTM! Maybe worth a note in a CHANGELOG, or a Changelog trailer in the commits (see also our future awesome release process for details).
... and add accessors instead. I'm going to change the inner structure of `SyncTimelineEvent`, meaning that access will have to be via an accessor in future. Let's start by making the fields private, and use accessors where we previously used direct access.
... and add accessors instead. Give `TimelineEvent` the same treatment we just gave `SyncTimelineEvent`: make the fields private, and use accessors where we previously used direct access.
I'm going to be replacing the inner structure of `TimelineEvent` with an implementation that holds a `Raw<AnySyncTimelineEvent>`, rather than a `Raw<AnyTimelineEvent>`. Prepare for that by changing the accessors to return `Raw<AnySyncTimelineEvent>`.
…eEvent>` Give `Timeline::into_raw()` the same treatmeant we just gave `Timeline::ra()`.
Pull out the bits of these classes which are dependent on success or otherwise of decrypting an event to a new enum.
These are no longer required now that the event itself lives in an inner class.
This is only used in one place, and is much better inlined anyway.
richvdh
force-pushed
the
rav/timeline_event_inner
branch
from
ba762a8 to
2401837
Compare
This was referenced Oct 15, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
As previously discussed, we'd like to replace the innards of
SyncTimelineEventandTimelineEventwith a new enum, so that we can accurately represent the three possible states of (Unencrypted, Decrypted, UnableToDecrypt).This PR lays the groundwork for that change by pulling out the enum. For now it only supports the Decrypted and PlainText cases: the UTD case is still mapped onto PlainText, and will change in a followup PR. It is essentially a reworking of #4053.
One potential point of contention is that I've used the same inner type for both
TimelineEventandSyncTimelineEvent: it seems to me that we never rely on the different type information, so having two implementations felt redundant. (It does mean thatTimelineEventandSyncTimelineEventbecome essentially identical, but replacing one with the other felt like a job for another day.) Anyway, I'm happy to revisit this and add a separateSyncTimelineEventKindor somesuch instead.Speaking of which, I'm also not entirely happy with the nameNow renamed toTimelineEventInner. When we discussed this, poljar spoke ofTimelineFooand I've not felt much more inspired since. If we could think of a decent name, I think the struct could usefully be exposed as a public type which might clean up some other bits of code. Suggestions welcome.TimelineEventKind.Unfortunately, this PR is necessarily somewhat large. I've tried to structure it in a way to make it easily reviewable, but let me know if I can help with review.
Part of #4048.