Make content::ResourceContext be a real interface like the rest of the Content API (i.e. don't ha...

Make content::ResourceContext be a real interface like the rest of the Content API (i.e. don't have setters/getters on it, and make all the functions pure virtual).

BUG=98716
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=121287

[jam, 2012-02-09 00:50:56]

This looks much bigger than it is, because I had to make all the ResourceContext
pointers not const.

[Elliot Glaysher, 2012-02-09 01:06:32]

+willchan for ProfileIO work

(all your other stuff lgtm, but wait for Will because I have no idea if this
breaks the subtleties of initialization.)

[willchan no longer on Chromium, 2012-02-09 19:48:06]

lgtm

[willchan no longer on Chromium, 2012-02-09 19:56:45]

Oh, I should have documented jam/my offline discussion about the change.
I've deferred to him since this rightly belongs to the content API, so it
makes sense to make it consistent with all the rest.

I personally like to mark objects that are conceptually const for the
lifetime of the process (ProfileIOData / ResourceContext) as const, even if
the const values are lazily initialized on first use. jam disagreed, for
the obvious reason that lazy initialization means the object is being
mutated. As content::ResourceContext is very widely used in content/ and I
trust jam's judgment with regards to how he wants to maintain that code
base, and ProfileIOData's scope is very small (it's basically only used
during initialization, and should *not* be widely accessible), the change
to ProfileIOData is minor and acceptable to me. I hope the addition of the
ProfileIOData::FromResourceContext() API does not lead to a proliferation
of ProfileIOData being accessed widely, as that would be very bad.

On Thu, Feb 9, 2012 at 11:48 AM, <willchan@chromium.org> wrote:

> lgtm
>
>
>
>
http://codereview.chromium.**org/9369009/<http://codereview.chromium.org/9369...
>