Have the native_rust_library be aware of the
underlying platform to communicate that information
during registration of the device
https://linear.app/comm/issue/ENG-4608
Depends on D8749
Details
Details
Android and iOS build
Can't be tested fully until native login if fully implmented.
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
| services/identity/src/database.rs | ||
|---|---|---|
| 89 ↗ | (On Diff #29904) | Also, we don't need Native, do we? |
| native/native_rust_library/src/lib.rs | ||
|---|---|---|
| 27 ↗ | (On Diff #29904) | unfortunately, this is how prost translates iOS |
| services/identity/src/database.rs | ||
| 80 ↗ | (On Diff #29904) | Thanks, I should have verified with the platforms under lib/ |
| 89 ↗ | (On Diff #29904) | Strictly speaking, no. But I could see a future where we want a "non-keyserver non-web" option as a fallback. |
| shared/protos/identity_client.proto | ||
|---|---|---|
| 111 ↗ | (On Diff #29904) | nvm this doesn't work. I think Ios = 3; is better, I think (Rust enum variant will be DeviceType::Ios). Less potential for confusion with "Input/Output". I don't feel strongly about it, though |
Comment Actions
We don't need native as an option here.
To deliberately avoid ambiguity, I explicitly enumerated the full list of device types you should support in two places: Phabricator and Comm ("How to differentiate between different Comm devices" thread under "Services team" channel).
It's already frustrating to me that I have to micromanage to this degree. Ideally I should not have to give you explicit guidance at all, but the fact that guidance is frequently ignored means that I need to review every single one of your diffs.
This is the same problem as in D7691. There is very little that frustrates me more than feeling like the effort I put into careful, thoughtful, explicit communication is wasted and ignored.
Comment Actions
We don't need native as an option here.
To deliberately avoid ambiguity, I explicitly enumerated the full list of device types you should support in two places: Phabricator and Comm ("How to differentiate between different Comm devices" thread under "Services team" channel).
It's already frustrating to me that I have to micromanage to this degree. Ideally I should not have to give you explicit guidance at all, but the fact that guidance is frequently ignored means that I need to review every single one of your diffs.
This is the same problem as in D7691. There is very little that frustrates me more than feeling like the effort I put into careful, thoughtful, explicit communication is wasted and ignored.
I kept it in case anyone had some data written which used it. Which would cause errors with their specific setup. Probably not an issue as I think most of the native_rust_library implementations are "there but not used".
Also, removal of enum entries from protobuf is an anti-patttern, as there may be stale devices which are still using the legacy paradigms. Once these gRPC endpoints get "launched publicly", we can no longer mutate protocol messages.
Seemed like a "doesn't hurt having the old paradigm in a deprecated state, but could cause issues removing it" situation.
Anyway, I'll remove it since I'm in the wrong.