Determine whether AccountFetcherService belongs inside IdentityManager |
|||
Issue descriptionTechnically, it could remain outside, as nothing currently slotted for the IdentityManager implementation depends on it. However, it is very closely tied in functionality to AccountTrackerService: AccountFetcherService asynchronously fetches metadata for accounts at various times (e.g., when the accounts are first added), which AccountTrackerService then stores. It would bring in some extra dependencies. We need to determine the answer to this question as AccountFetcherService depends on ProfileOAuth2TokenService and AccountTrackerService, so it either needs to be brought in or converted to use IdentityManager.
,
Dec 10
This also of course will determine whether FakeAccountFetcherService is inside; like the production one, it directly depends on both AccountTrackerService and ProfileOAuth2TokenService.
,
Dec 13
Mario pointed out on https://docs.google.com/document/d/1kLjnxPnBAX0G6W-3u6OF_VguuJc0pXdgCRVR0z3yn-g/edit# that this question also impacts the flow of account removal: currently, AccountFetcherService observes token revocation and removes the account from AccountTrackerService. If we leave AccountFetcherService outside, then nothing inside would guarantee that the account's metadata is removed when its refresh token is revoked. This intuitively seems wrong.
,
Dec 13
AccountFetcherService cannot be untangled from AccountTrackerService. They are conceptually a single service. AFS directly calls ATS private methods, ATS invariants are enforced by AFS, ATS state is updated by AFS. ATS could be simply a std::vector<AccountInfo> owned by AFS, and its methods moved to different objects and/or free functions.
,
Dec 14
This makes complete sense, Sylvain! So there's a clear resolution here that AccountFetcherService belongs inside IdentityManager. |
|||
►
Sign in to add a comment |
|||
Comment 1 by blundell@chromium.org
, Dec 4Cc: sdefresne@chromium.org