Some features (like Wallet) need to know the current syncing account, and whether or not the user has full sync enabled.
We have roughly 2 options:
1. They can observe ProfileSyncService, which already exposes this state.
Pro: This already exists, and lives on the main thread, where most features likely need it.
Con: ProfileSyncService contains the *global* sync state across the profile. Since with USS, we already tell the feature which state we're in through the bridge, it would be cleaner if features could just use that.
Con: ProfileSyncService is already exposing too much state, would be nice to cut that down.
2. Features can observer their bridge to learn what the sync state is.
Pro: This is a very localized call, and supports future scenarios where different features have different states.
Con: For some features (like autofill, Payments), the bridge runs on the DB thread, while both the Sync state and the feature are on the main thread. This causes a lot of thread hopping, with potential for race conditions.
Comment 1 by feuunk@chromium.org
, Sep 26Status: Duplicate (was: Assigned)