| commit | de2a09991f24a82373e812d5fbb336c1805b5160 | [log] [tgz] |
|---|---|---|
| author | Mikel Astiz <[email protected]> | Tue Oct 13 13:45:09 2020 |
| committer | Commit Bot <[email protected]> | Tue Oct 13 13:45:09 2020 |
| tree | ab6e014fd9a1e05266904eb5fc4c26b0adaadb30 | |
| parent | f08012070f01a0f4276fa5c2345e5f7ee741fdfd [diff] |
[sync] Remove GetSyncableServiceForType() from SyncClient This historic mechanism to inject dependencies into ProfileSyncService doesn't belong in SyncClient (dependencies to core sync logic / engine itself), and it's questionable whether it should remain in this form in BrowserSyncClient, where feature-specific dependencies are injected, and where multiple similar approaches coexist. Arguably, the most elegant and universal way to inject a dependency to a sync controller is to have full access to the KeyedService that owns the local model. Most controllers are simple and don't actually need this: all they need is a SyncableService or ModelTypeControllerDelegate. However, that introduces code inconsistencies that can be confusing. In this patch, the approach is unified for the remaining SyncableService types, after migrating history delete directives and preferences). The corresponding keyed services are directly injected via BrowserSyncClient and hence SyncClient::GetSyncableServiceForType() can be deleted. Change-Id: I8e80482e8657624dc7c1e15b6bcf0409ae4d1336 Bug: 915154 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2463617 Reviewed-by: Marc Treib <[email protected]> Commit-Queue: Mikel Astiz <[email protected]> Cr-Commit-Position: refs/heads/master@{#816550}
ChromiumChromium is an open-source browser project that aims to build a safer, faster, and more stable way for all users to experience the web.
The project's web site is https://www.chromium.org.
Documentation in the source is rooted in docs/README.md.
Learn how to Get Around the Chromium Source Code Directory Structure .
For historical reasons, there are some small top level directories. Now the guidance is that new top level directories are for product (e.g. Chrome, Android WebView, Ash). Even if these products have multiple executables, the code should be in subdirectories of the product.