Migrate HostReferralList and StartupDNSPrefetchList from local_state to user ...

Migrate HostReferralList and StartupDNSPrefetchList from local_state to user preferences, in preparation for multi-profile.

BUG=66717
TEST=none.


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=69320

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=69412

[jar (doing other things), 2010-12-13 20:27:28]

A few questions below.

I've also copied Tony, since he's generally the expert on profile use and its
interface.

http://codereview.chromium.org/5800004/diff/6001/chrome/browser/net/predictor...
File chrome/browser/net/predictor_api.cc (right):

http://codereview.chromium.org/5800004/diff/6001/chrome/browser/net/predictor...
chrome/browser/net/predictor_api.cc:394:
(local_state->FindPreference(prefs::kDnsHostReferralList)) ?
If this is where you migrate the data, perhaps it should be where you delete old
data (and not just copy it).

...thinking about this some more... 

This data is all "learned data" used for optimizing connections (and startup). 
It would not be  the worst thing if you simply discarded old data (i.e.,
critical stuff would be relearned quickly enough).

The critical point IMO is the discard of old data, both for efficiency, and for
security.  I'm not a profiles expert, so that is the detail I'm most curious
about.

http://codereview.chromium.org/5800004/diff/6001/chrome/browser/prefs/browser...
File chrome/browser/prefs/browser_prefs.cc (left):

http://codereview.chromium.org/5800004/diff/6001/chrome/browser/prefs/browser...
chrome/browser/prefs/browser_prefs.cc:93:
chrome_browser_net::RegisterPrefs(local_state);
Where, if anywhere, are the new prefs declared (registered?)?

Without a registration call, can you still read old prefs?

[Miranda Callahan, 2010-12-14 01:03:49]

Ok -- addressed your concerns, and also slightly reorganized the prefs:
standardized their names to lower_case_with_underscore, as used throughout
preferences, and put StartupPrefetchList and HostReferralList in the "dns"
section of the user_preferences.  I also added a data version int value to
profiles that I can update to keep migration and/or deletion and recreation
tidy.

http://codereview.chromium.org/5800004/diff/6001/chrome/browser/net/predictor...
File chrome/browser/net/predictor_api.cc (right):

http://codereview.chromium.org/5800004/diff/6001/chrome/browser/net/predictor...
chrome/browser/net/predictor_api.cc:394:
(local_state->FindPreference(prefs::kDnsHostReferralList)) ?
On 2010/12/13 20:27:29, jar wrote:
> If this is where you migrate the data, perhaps it should be where you delete
old
> data (and not just copy it).
> 
> ...thinking about this some more... 
> 
> This data is all "learned data" used for optimizing connections (and startup).

> It would not be  the worst thing if you simply discarded old data (i.e.,
> critical stuff would be relearned quickly enough).
> 
> The critical point IMO is the discard of old data, both for efficiency, and
for
> security.  I'm not a profiles expert, so that is the detail I'm most curious
> about.

I think everything you say about deleting old data makes great sense.  Changed
the code to reflect this idea.

http://codereview.chromium.org/5800004/diff/6001/chrome/browser/prefs/browser...
File chrome/browser/prefs/browser_prefs.cc (left):

http://codereview.chromium.org/5800004/diff/6001/chrome/browser/prefs/browser...
chrome/browser/prefs/browser_prefs.cc:93:
chrome_browser_net::RegisterPrefs(local_state);
On 2010/12/13 20:27:29, jar wrote:
> Where, if anywhere, are the new prefs declared (registered?)?
> 
> Without a registration call, can you still read old prefs?

I added the new user pref registration to RegisterUserPrefs in predictor_api.cc.
 Very good point that I won't be able to read the old prefs!  :-)  I like your
answer in the previous comment that we could discard and delete the data in
local_state. Not only will it be quickly rebuilt, but it'll save a migration
check on startup.

[jar (doing other things), 2010-12-14 08:18:26]

LGTM

To verify that this persistence is working (in the new world):

Visit some sites, like cnn.com.

Visit about:dns

Notice  that there is a startup list.
Notice that there is a referral list.

Close most of your tabs, except about:dns

Exit browser and restart (bring up just the about:dns tab)
Verify that the referral list is still somewhat intact (it was persisted, and
restored).

Also, using an ASCII editor, verify that the old pref has deleted.

thx!

[Miranda Callahan, 2010-12-15 17:28:36]

On 2010/12/14 08:18:26, jar wrote:
> LGTM
> 
> To verify that this persistence is working (in the new world):
> 
> Visit some sites, like http://cnn.com.
> 
> Visit about:dns
> 
> Notice  that there is a startup list.
> Notice that there is a referral list.
> 
> Close most of your tabs, except about:dns
> 
> Exit browser and restart (bring up just the about:dns tab)
> Verify that the referral list is still somewhat intact (it was persisted, and
> restored).
> 
> Also, using an ASCII editor, verify that the old pref has deleted.
> 
> thx!

Thanks for the test explanation -- yes, it looks like it passes.  :-)