Skip to content
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

Initial implementation #4

Merged
merged 108 commits into from
Jun 10, 2021
Merged

Initial implementation #4

merged 108 commits into from
Jun 10, 2021

Conversation

oxtoacart
Copy link
Contributor

  • Do the tests pass? Consistently?
  • Did this change improve test coverage?
  • Has it been reviewed/approved by relevant teammates?
  • Can it be QA’d in staging or something like staging?
  • Is the code in question being linted? If not, consider adding a linter step to CI. If yes, make sure the linter is happy.
  • Do we know how we’re going to deploy this?
  • Are we clear on what the support and maintenance impact is?
  • Did you create new documentation? Is it accessible and in the right place?

… than previously recorded mostRecentMessageTime
@@ -0,0 +1,62 @@
# messaging-android

## Data Model
Copy link

@atavism atavism May 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we possibly add a brief overview to the top of the README instead of starting out with the data model? That this is an Android messaging library, Lantern Android integrates it, it re-uses code from Signal's protocol, etc?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Let me know if there's anything else you'd like to see in there.

@atavism
Copy link

atavism commented May 11, 2021

@oxtoacart Just to clarify, is there a PR yet on https://github.com/getlantern/android-lantern with only your messaging changes or are all those on the ox/flutterport branch already?

@oxtoacart
Copy link
Contributor Author

@oxtoacart Just to clarify, is there a PR yet on https://github.com/getlantern/android-lantern with only your messaging changes or are all those on the ox/flutterport branch already?

No, there's no PR yet, we're working on a very long-lived ox/messaging branch.

Metadata.analyze(file, mimeType)
} catch (t: Throwable) {
logger.error("couldn't analyze metadata: ${t.message}")
null
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we present any sort of error to the user if creating/storing an attachment fails?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if creating the attachment fails (like if there's a problem writing to disk), we'll throw an exception that can be handled by the UI. This particular branch just means that we couldn't extract metadata for the attachment, which doesn't prevent us from creating the attachment, it just means we don't have any metadata. That particular case is not indicated to the user, which I think is okay since there's nothing they could do about it anyway.

Copy link

@hwh33 hwh33 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome work @oxtoacart, this looks great! I've looked at everything but the tests so far. I left a number of comments, but I think a lot of them are just clarifying questions. I ended up looking at db-android a bit - cool stuff! Nice all around really

## Protocol Buffers
messaging-android communicates with Tassis and internally stores data using protocol buffers.
Messages exchanged with tassis are defined in [Messages.proto](messaging/src/main/protos/Messages.proto),
which is just a copy of the protocol buffers defined in [tassis](https://github.com/getlantern/tassis/blob/main/model/Messages.proto).
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There must be a better way of sharing this model. Perhaps a repo which defines the shared models, even if it's currently only this file?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm on the fence about this. I agree it's a little iffy to copy it, but OTOH a git submodule for just one file seems like a lot of work of its own.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a compromise of sorts: what if you added a note at the top of this file like:

Copy of getlantern/tassis/model/Messages.proto
Version: 39ca42e
If you update this file, please update this note as well.

messaging/src/main/protos/Messages.proto Show resolved Hide resolved

package tassis;

option go_package = "github.com/getlantern/tassis/model";
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

model is not a great name for a Go package. Will there be no other users of this model? In that case, maybe it could be an internal package? If there will be external users, then maybe it could just go directly in getlantern/tassis? Or maybe getlantern/tassis/tassismsg?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's wrong with model?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's generic; it doesn't convey any meaning about the contents. This may not be the model for importers outside of the tassis world. Other importers may have their own models for storing messages and other constructs defined in model.
As an analogy, it's like having a protocol library with subpackages client and server. Importers can always alias it as tassismodel or whatever they like, but then everyone is referring to your package differently.

If you're particularly tied to model, I won't fight you on it, but I do think it makes for awkward usage.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, now I understand. Let me think about that.

messaging/src/main/protos/Messages.proto Outdated Show resolved Hide resolved
messaging/src/main/protos/Messages.proto Show resolved Hide resolved
messaging/src/main/java/io/lantern/messaging/Messaging.kt Outdated Show resolved Hide resolved
@oxtoacart
Copy link
Contributor Author

Thanks for the comments @hwh33! I've responded to all and implemented some :)

@hwh33
Copy link

hwh33 commented Jun 9, 2021

No problem! It's looking great. There are actually a number of additional comments. I think they might have been buried in the "hidden conversations" expander (see screenshot below). Probably on me for leaving so many 😅

image

@oxtoacart
Copy link
Contributor Author

There are actually a number of additional comments

Thanks! Will look.

@oxtoacart
Copy link
Contributor Author

@hwh33 Thanks for the awesome level of comments! I think I've provided answers to the remaining comments. Please let me know what you think.

@oxtoacart
Copy link
Contributor Author

Okay, I've got more changes to make but I don't want to make this PR any bigger, so I'm going to go ahead and merge. If there's any issues with the code in here, we can open a new PR to address those.

@oxtoacart oxtoacart merged commit b3f7ecf into main Jun 10, 2021
@oxtoacart oxtoacart deleted the ox/newwebsocket branch June 10, 2021 19:01
@hwh33
Copy link

hwh33 commented Jun 11, 2021

Awesome work @oxtoacart!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants