-
Notifications
You must be signed in to change notification settings - Fork 6
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
chore: add pbandk protobuf (AR-1303) #301
Conversation
val content = when (val protoContent = genericMessage.content) { | ||
is GenericMessage.Content.Text -> MessageContent.Text(protoContent.value.content) | ||
is GenericMessage.Content.Asset -> MessageContent.Unknown | ||
is GenericMessage.Content.Availability -> MessageContent.Unknown | ||
is GenericMessage.Content.ButtonAction -> MessageContent.Unknown | ||
is GenericMessage.Content.ButtonActionConfirmation -> MessageContent.Unknown | ||
is GenericMessage.Content.Calling -> MessageContent.Unknown | ||
is GenericMessage.Content.Cleared -> MessageContent.Unknown | ||
is GenericMessage.Content.ClientAction -> MessageContent.Unknown | ||
is GenericMessage.Content.Composite -> MessageContent.Unknown | ||
is GenericMessage.Content.Confirmation -> MessageContent.Unknown | ||
is GenericMessage.Content.DataTransfer -> MessageContent.Unknown | ||
is GenericMessage.Content.Deleted -> MessageContent.Unknown | ||
is GenericMessage.Content.Edited -> MessageContent.Unknown | ||
is GenericMessage.Content.Ephemeral -> MessageContent.Unknown | ||
is GenericMessage.Content.External -> MessageContent.Unknown | ||
is GenericMessage.Content.Hidden -> MessageContent.Unknown | ||
is GenericMessage.Content.Image -> MessageContent.Unknown | ||
is GenericMessage.Content.Knock -> MessageContent.Unknown | ||
is GenericMessage.Content.LastRead -> MessageContent.Unknown | ||
is GenericMessage.Content.Location -> MessageContent.Unknown | ||
is GenericMessage.Content.Reaction -> MessageContent.Unknown | ||
null -> { | ||
kaliumLogger.w("Null content when parsing protobuf. Message UUID = $genericMessage.") | ||
MessageContent.Unknown | ||
} | ||
} |
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.
Exhaustive when
for protobufs as the Content
is a sealed class!
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.
Great work!
I just have two comments 🤔
logic/src/commonTest/kotlin/com/wire/kalium/logic/data/message/ProtoContentMapperProvider.kt
Outdated
Show resolved
Hide resolved
|
||
import "qualified_user_id.proto"; | ||
|
||
message GenericMessage { |
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.
The proto files are copied into the project now? This makes it hard to know which of the protobuf file we are using in Kalium.
Can we pull them GitHub only define the release tag in the project. If this is not easy we could do it in a separate PR but I think we should do it.
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.
Not 100% copy pasted. As I mentioned in the PR description, the QualifiedUserID, for example, needed to be extracted to a common file.
Some of the Java options supported by Protoc (like outer class name or adding a suffix) are not respected when using PBandK.
I'd like to streamline the process and checkout from the otr-proto repo, but it's far from easy to do so right now. Maybe it would help by extracting the QualifiedUserID in the original otr-proto repo, but that would be a breaking change.
I don't have any solutions now.
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.
The otr.proto
and messages.proto
are supposed to live in different namesakes doesn't PBandK respect that? See wireapp/generic-message-proto#74 (review)
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.
So yeah, seems like streem/pbandk#179 doesn't respect package
but also the option java_package
is different so I don't understand why they clash.
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.
Right so it clashes because package name inside the proto files are override by the plugin option:
option("kotlin_package=com.wire.kalium.protobuf")
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.
TBH I felt like PBandK doesn't respect a lot of these options yet. I tried playing with them before submitting the PR and in the end I just removed them, as they didn't have any effect on the generated code.
I didn't want to leave package
and option
s in there, so they would suddenly kick-in when we bump PBandK's version or someone spends time trying to understand these lines of code in the future.
It's a trade-off for now. We increase a bit of maintenance with .proto
definitions, but as a pro: we have a multi-platform solution. In my opinion, it's worth it. But I'd like a second confirmation before we move on.
Hopefuly these will be supported Soon™.
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.
Yes, it's definitely worth it! Just looking for way to avoid having to copy & paste the files and edit them. But like I said earlier I'm not pushing for solving it in this PR.
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.
Right so it clashes because package name inside the proto files are override by the plugin option:
option("kotlin_package=com.wire.kalium.protobuf")
Indeed, the kotlin_package
was overwriting it 🤦🏼♂️. Removing that made the package
work.
Still, the original messages.proto
doesn't have a package
. So we still need to modify the files a tiny bit when getting from the original repo. But the changes are one-liner.
This simplifies our process of getting proto definitions from otr-proto, and only requires changing the package name. Everything else is 100% the same.
PR Submission Checklist for internal contributors
The PR Title
SQPIT-764
The PR Description
What's new in this PR?
Issues
We need a multiplatform protobuf solution that covers all our usecases
Solutions
Add PBandK.
How it is setup:
Two new modules:
protobuf-codegen
which is a "Java Library" that includes the.proto
files. It will call Google's Gradle Protobuf plugin to generate the code, with the PBandK add-on.protobuf
which is a bit of a hack, as Google's Protobuf plugin doesn't work with Kotlin Multiplatform yet. This module depends onprotobuf-codegen
and will trigger a code generation there, adding the generated files to thecommonMain
SourceSet. This module also contains the PBandK incommonMain
, which allows all targets to encode and decode to/from byte arrays.The idea was taken from a sample in pbandk's repo. As suggested in this issue/discussion.
Testing
Add a simple test to serve as a sample and sanity check.
Notes
.proto
files are copy/pasted from our generic-message-proto repo.messages.proto
andotr.proto
contained aQualifiedUserID
. So I've extracted it to its own dedicated file calledqualified_user_id.proto
.ClientId
andUserId
, which can be misleading, making discoverability through autocompletion a bit annoying.PR Post Merge Checklist for internal contributors
References
feat(conversation-list): Sort conversations by most emojis in the title #SQPIT-764
.