Benefits: We can get rid of the ResourceBundle, new chrome versions won't need to re-download the component, and chrome://components will always show what version is actually being used.


From email thread:

From: waffles@

Oh, I'll also toss in this idea: we support the idea of a "bundled component": the component updater will then look in DIR_USER_DATA/FileTypePolicies/$version for component versions as well as DIR_MODULE/FileTypePolicies.

So one idea would be to twiddle the build so that download_file_types.pb ends up in DIR_MODULE/FileTypePolicies, e.g. /opt/google/chrome/FileTypePolicies on Linux (or ./out/build_dir/FileTypePolicies for a local build), along with a manifest.json with contents like the following:
{
  "manifest_version": 2,
  "name": "fileTypePolicies",
  "version": "5"
}
Then, when the browser starts the component updater on Canary would recognize that version 5 is in DIR_MODULE and ignore (in fact, clean up) the version 4 in DIR_USER_DATA. This has the additional advantage that people with a built-in version 5 won't have to download a component version 5 (which they will then never really use). It might also simplify some of your code around how the list is loaded, since then you'll only have one code path to load the list (via ComponentReady), and that will be guaranteed to be called in every run of Chrome with the latest list available.