-
Notifications
You must be signed in to change notification settings - Fork 249
Async Rust ADR #6549
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
base: main
Are you sure you want to change the base?
Async Rust ADR #6549
Conversation
| @@ -0,0 +1,256 @@ | |||
| diff --git a/mobile/android/android-components/components/feature/fxsuggest/build.gradle b/mobile/android/android-components/components/feature/fxsuggest/build.gradle | |||
| index d5b717c0ef..28d9c82eb2 100644 | |||
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 wasn't sure the best way to communicate these changes, but I went with checking in diffs because I wanted to make sure they never expired. I can put these into a github PR or phab patch if people want, maybe those would look nicer.
686b62c to
de5b7c8
Compare
|
I updated this after our meeting yesterday:
With this change, I could get behind option A. I think we could solve the worst issue, which is how the functionality is split across different repos/languages and easy to forget about when you're writing Rust code. The impact on the docs is unfortunate, but not really a deal-breaker. That said, I still like option C the best. I like that it makes the code we write match more closely with how consumers are using it and it opens up new possibilities for the future. I also don't see much downside/risk personally. |
There hasn't been agreement on a grand vision for async Rust in app-services (mozilla#6549). I think part of the reason is that ADR is discussing too many things. This is my attempt to take a small change from that ADR and see if we agree. This change takes the async wrapping code that's currently in android-components and moves it to our app-services wrapper. This improves the API boundary IMO. The SYNC team and the credentials management teams are responsible for threading issues like how to avoid blocking too many threads when we're waiting on the primary password dialog. Therefore, the code that affects this should be owned by us. In more practical terms, I have some ideas on how to improve our threading strategy and it's simpler to think about those changes if all the code is in one repo. Here's the corresponding android-components change: https://phabricator.services.mozilla.com/D253666 What do others think? Is this a good idea? Do we need/want an ADR for this?
There hasn't been agreement on a grand vision for async Rust in app-services (mozilla#6549). I think part of the reason is that ADR is discussing too many things. This is my attempt to take a small change from that ADR and see if we agree. This change takes the async wrapping code that's currently in android-components and moves it to our app-services wrapper. This improves the API boundary IMO. The SYNC team and the credentials management teams are responsible for threading issues like how to avoid blocking too many threads when we're waiting on the primary password dialog. Therefore, the code that affects this should be owned by us. In more practical terms, I have some ideas on how to improve our threading strategy and it's simpler to think about those changes if all the code is in one repo. Here's the corresponding android-components change: https://phabricator.services.mozilla.com/D253666 If we agree on this, then I think we can do something similar for iOS. What do others think? Is this a good idea? Do we need/want an ADR for this?
There hasn't been agreement on a grand vision for async Rust in app-services (mozilla#6549). I think part of the reason is that ADR is discussing too many things. This is my attempt to take a small change from that ADR and see if we agree. This change takes the async wrapping code that's currently in android-components and moves it to our app-services wrapper. This improves the API boundary IMO. The SYNC team and the credentials management teams are responsible for threading issues like how to avoid blocking too many threads when we're waiting on the primary password dialog. Therefore, the code that affects this should be owned by us. In more practical terms, I have some ideas on how to improve our threading strategy and it's simpler to think about those changes if all the code is in one repo. Here's the corresponding android-components change: bendk/firefox@d038ba6 If we agree on this, then I think we can do something similar for iOS. What do others think? Is this a good idea? Do we need/want an ADR for this?
There hasn't been agreement on a grand vision for async Rust in app-services (mozilla#6549). I think part of the reason is that ADR is discussing too many things. This is my attempt to take a small change from that ADR and see if we agree. This change takes the async wrapping code that's currently in android-components and moves it to our app-services wrapper. This improves the API boundary IMO. The SYNC sync and the credentials management teams are responsible for threading issues. For example, we're the one's thinking through how to avoid blocking too many threads when we're waiting on the primary password dialog. Since we're responsible for threading issues, we should own the code On a practical level: I have some ideas on how to improve our threading strategy and it's simpler to think about those changes if all the code is in one repo. Here's the corresponding android-components change: bendk/firefox@d038ba6 If we agree on this, then I think we can do something similar for iOS. What do others think? Is this a good idea? Do we need/want an ADR for this?
There hasn't been agreement on a grand vision for async Rust in app-services (mozilla#6549). I think part of the reason is that ADR is discussing too many things. This is my attempt to take a small change from that ADR and see if we agree. This change takes the async wrapping code that's currently in android-components and moves it to our app-services wrapper. This improves the API boundary IMO. The SYNC sync and the credentials management teams are responsible for threading issues. For example, we're the one's thinking through how to avoid blocking too many threads when we're waiting on the primary password dialog. Since we're responsible for threading issues, we should own the code On a practical level: I have some ideas on how to improve our threading strategy and it's simpler to think about those changes if all the code is in one repo. Here's the corresponding android-components change: bendk/firefox@d038ba6 If we agree on this, then I think we can do something similar for iOS. What do others think? Is this a good idea? Do we need/want an ADR for this?
This is my new version of #5910, which is more focused and more concrete. Maybe we're finally ready to actually make a decision here 🤞
Pull Request checklist
[ci full]to the PR title.Branch builds: add
[firefox-android: branch-name]to the PR title.