Renamed the dns_prefetch component to network_predictor

Renamed the dns_prefetch component to network_predictor

This is in preparation for adding preconnect support which goes through
the same underlying plumbing.  dns_prefetch was too restrictive of a
component name and was only exposing the single method.

There are no functionality changes in this CL, just the rename (the namespace was also renamed)

BUG=450682
Committed: https://crrev.com/ed4b6f8b7392eb64fc664aa49f2627ecb5fdc073
Cr-Commit-Position: refs/heads/master@{#314001}

[Pat Meenan, 2015-01-21 21:37:39]

pmeenan@chromium.org changed reviewers:
+ mmenke@chromium.org, ttuttle@chromium.org

[Pat Meenan, 2015-01-21 21:37:39]

mmenke@chromium.org, ttuttle@chromium.org: Sending it out to the net owners
first to make sure the rename is appropriate or if you'd prefer me to just
append the preconnect logic onto the dns_prefetch component without renaming it.

[gunsch, 2015-01-21 21:45:16]

On 2015/01/21 21:37:39, Pat Meenan wrote:
> mailto:mmenke@chromium.org, mailto:ttuttle@chromium.org: Sending it out to the
net owners
> first to make sure the rename is appropriate or if you'd prefer me to just
> append the preconnect logic onto the dns_prefetch component without renaming
it.

chromecast/ rs lgtm

[mmenke, 2015-01-21 21:49:34]

On 2015/01/21 21:37:39, Pat Meenan wrote:
> mailto:mmenke@chromium.org, mailto:ttuttle@chromium.org: Sending it out to the
net owners
> first to make sure the rename is appropriate or if you'd prefer me to just
> append the preconnect logic onto the dns_prefetch component without renaming
it.

I'm fine with renaming the class (Though I'm not familiar with the dns_prefetch
component - you should make sure ttuttle's happy as well).  My concern is that
we'd have predictor.h and network_predictor.h, which seems very confusing
(admittedly, we had renderer_net_predictor and predictor before as well, which
had the same issue).  Moreover, neither predictor.h not renderer_net_predictor.h
has class level docs saying what they do.  They both have docs saying how they
do the mysterious thing they do, curiously.

I'd really like to see the situation cleaned up while you're mucking with this
code.  I don't have any suggestions - happy to spend some time digging through
the code so I can provide more useful feedback.

[Deprecated (see juliatuttle), 2015-01-21 22:04:35]

On 2015/01/21 21:37:39, Pat Meenan wrote:
> mailto:mmenke@chromium.org, mailto:ttuttle@chromium.org: Sending it out to the
net owners
> first to make sure the rename is appropriate or if you'd prefer me to just
> append the preconnect logic onto the dns_prefetch component without renaming
it.

rename lgtm; agree with mmenke that things could use some clarification and
documentation while you're there if you have time.

[mmenke, 2015-01-22 16:45:01]

On 2015/01/21 22:04:35, ttuttle wrote:
> On 2015/01/21 21:37:39, Pat Meenan wrote:
> > mailto:mmenke@chromium.org, mailto:ttuttle@chromium.org: Sending it out to
the
> net owners
> > first to make sure the rename is appropriate or if you'd prefer me to just
> > append the preconnect logic onto the dns_prefetch component without renaming
> it.
> 
> rename lgtm; agree with mmenke that things could use some clarification and
> documentation while you're there if you have time.

Here's my suggestion:

The updated renderer class ("network_predictor") doesn't actually "predict"
anything, it just responds to prefetch hints.  I suggest just calling it the
network_prefetcher, or even just the prefetcher (Preloader is another option,
but I've seen that used to refer just to prerendering before, and that has its
own renderer-side class).  renderer_net_predictor should also be renamed.

I'm certainly open to other ideas, but I do feel that network_predictor is both
the wrong name for the component, and makes for confusion with the predictor
class which does actually predict stuff.

[Pat Meenan, 2015-01-22 16:50:46]

On 2015/01/22 16:45:01, mmenke wrote:
> On 2015/01/21 22:04:35, ttuttle wrote:
> > On 2015/01/21 21:37:39, Pat Meenan wrote:
> > > mailto:mmenke@chromium.org, mailto:ttuttle@chromium.org: Sending it out to
> the
> > net owners
> > > first to make sure the rename is appropriate or if you'd prefer me to just
> > > append the preconnect logic onto the dns_prefetch component without
renaming
> > it.
> > 
> > rename lgtm; agree with mmenke that things could use some clarification and
> > documentation while you're there if you have time.
> 
> Here's my suggestion:
> 
> The updated renderer class ("network_predictor") doesn't actually "predict"
> anything, it just responds to prefetch hints.  I suggest just calling it the
> network_prefetcher, or even just the prefetcher (Preloader is another option,
> but I've seen that used to refer just to prerendering before, and that has its
> own renderer-side class).  renderer_net_predictor should also be renamed.
> 
> I'm certainly open to other ideas, but I do feel that network_predictor is
both
> the wrong name for the component, and makes for confusion with the predictor
> class which does actually predict stuff.

Only reason I was using predictor is that it is the external interface wired
into the predictor logic which is where the prefetch and preconnects are
handled.  On the chance that we ever decided to expose other predictor
interfaces.  Prefetcher would probably be over-reaching because actual fetch
requests don't go through there and the preloader/prefetch interfaces get routed
through the main net interfaces.

I could rename it to something like network_hints which would closer align with
what dns-prefetch and preconnect actually do and still keep it generic enough
that other future hints could be added in if we needed.

[mmenke, 2015-01-22 16:52:58]

On 2015/01/22 16:50:46, Pat Meenan wrote:
> On 2015/01/22 16:45:01, mmenke wrote:
> > On 2015/01/21 22:04:35, ttuttle wrote:
> > > On 2015/01/21 21:37:39, Pat Meenan wrote:
> > > > mailto:mmenke@chromium.org, mailto:ttuttle@chromium.org: Sending it out
to
> > the
> > > net owners
> > > > first to make sure the rename is appropriate or if you'd prefer me to
just
> > > > append the preconnect logic onto the dns_prefetch component without
> renaming
> > > it.
> > > 
> > > rename lgtm; agree with mmenke that things could use some clarification
and
> > > documentation while you're there if you have time.
> > 
> > Here's my suggestion:
> > 
> > The updated renderer class ("network_predictor") doesn't actually "predict"
> > anything, it just responds to prefetch hints.  I suggest just calling it the
> > network_prefetcher, or even just the prefetcher (Preloader is another
option,
> > but I've seen that used to refer just to prerendering before, and that has
its
> > own renderer-side class).  renderer_net_predictor should also be renamed.
> > 
> > I'm certainly open to other ideas, but I do feel that network_predictor is
> both
> > the wrong name for the component, and makes for confusion with the predictor
> > class which does actually predict stuff.
> 
> Only reason I was using predictor is that it is the external interface wired
> into the predictor logic which is where the prefetch and preconnects are
> handled.  On the chance that we ever decided to expose other predictor
> interfaces.  Prefetcher would probably be over-reaching because actual fetch
> requests don't go through there and the preloader/prefetch interfaces get
routed
> through the main net interfaces.
> 
> I could rename it to something like network_hints which would closer align
with
> what dns-prefetch and preconnect actually do and still keep it generic enough
> that other future hints could be added in if we needed.

I'm perfectly happy with network_hints.

[Pat Meenan, 2015-01-22 19:56:26]

On 2015/01/22 16:52:58, mmenke wrote:
> On 2015/01/22 16:50:46, Pat Meenan wrote:
> > On 2015/01/22 16:45:01, mmenke wrote:
> > > On 2015/01/21 22:04:35, ttuttle wrote:
> > > > On 2015/01/21 21:37:39, Pat Meenan wrote:
> > > > > mailto:mmenke@chromium.org, mailto:ttuttle@chromium.org: Sending it
out
> to
> > > the
> > > > net owners
> > > > > first to make sure the rename is appropriate or if you'd prefer me to
> just
> > > > > append the preconnect logic onto the dns_prefetch component without
> > renaming
> > > > it.
> > > > 
> > > > rename lgtm; agree with mmenke that things could use some clarification
> and
> > > > documentation while you're there if you have time.
> > > 
> > > Here's my suggestion:
> > > 
> > > The updated renderer class ("network_predictor") doesn't actually
"predict"
> > > anything, it just responds to prefetch hints.  I suggest just calling it
the
> > > network_prefetcher, or even just the prefetcher (Preloader is another
> option,
> > > but I've seen that used to refer just to prerendering before, and that has
> its
> > > own renderer-side class).  renderer_net_predictor should also be renamed.
> > > 
> > > I'm certainly open to other ideas, but I do feel that network_predictor is
> > both
> > > the wrong name for the component, and makes for confusion with the
predictor
> > > class which does actually predict stuff.
> > 
> > Only reason I was using predictor is that it is the external interface wired
> > into the predictor logic which is where the prefetch and preconnects are
> > handled.  On the chance that we ever decided to expose other predictor
> > interfaces.  Prefetcher would probably be over-reaching because actual fetch
> > requests don't go through there and the preloader/prefetch interfaces get
> routed
> > through the main net interfaces.
> > 
> > I could rename it to something like network_hints which would closer align
> with
> > what dns-prefetch and preconnect actually do and still keep it generic
enough
> > that other future hints could be added in if we needed.
> 
> I'm perfectly happy with network_hints.

ok, just got everything renamed as network_hints.  I'll go through and add
class-level docs in a follow-on patchset so it will be easier to make out (as
part of this CL).

[mmenke, 2015-01-22 19:59:03]

On 2015/01/22 19:56:26, Pat Meenan wrote:
> On 2015/01/22 16:52:58, mmenke wrote:
> > On 2015/01/22 16:50:46, Pat Meenan wrote:
> > > On 2015/01/22 16:45:01, mmenke wrote:
> > > > On 2015/01/21 22:04:35, ttuttle wrote:
> > > > > On 2015/01/21 21:37:39, Pat Meenan wrote:
> > > > > > mailto:mmenke@chromium.org, mailto:ttuttle@chromium.org: Sending it
> out
> > to
> > > > the
> > > > > net owners
> > > > > > first to make sure the rename is appropriate or if you'd prefer me
to
> > just
> > > > > > append the preconnect logic onto the dns_prefetch component without
> > > renaming
> > > > > it.
> > > > > 
> > > > > rename lgtm; agree with mmenke that things could use some
clarification
> > and
> > > > > documentation while you're there if you have time.
> > > > 
> > > > Here's my suggestion:
> > > > 
> > > > The updated renderer class ("network_predictor") doesn't actually
> "predict"
> > > > anything, it just responds to prefetch hints.  I suggest just calling it
> the
> > > > network_prefetcher, or even just the prefetcher (Preloader is another
> > option,
> > > > but I've seen that used to refer just to prerendering before, and that
has
> > its
> > > > own renderer-side class).  renderer_net_predictor should also be
renamed.
> > > > 
> > > > I'm certainly open to other ideas, but I do feel that network_predictor
is
> > > both
> > > > the wrong name for the component, and makes for confusion with the
> predictor
> > > > class which does actually predict stuff.
> > > 
> > > Only reason I was using predictor is that it is the external interface
wired
> > > into the predictor logic which is where the prefetch and preconnects are
> > > handled.  On the chance that we ever decided to expose other predictor
> > > interfaces.  Prefetcher would probably be over-reaching because actual
fetch
> > > requests don't go through there and the preloader/prefetch interfaces get
> > routed
> > > through the main net interfaces.
> > > 
> > > I could rename it to something like network_hints which would closer align
> > with
> > > what dns-prefetch and preconnect actually do and still keep it generic
> enough
> > > that other future hints could be added in if we needed.
> > 
> > I'm perfectly happy with network_hints.
> 
> ok, just got everything renamed as network_hints.  I'll go through and add
> class-level docs in a follow-on patchset so it will be easier to make out (as
> part of this CL).

Thanks so much!

[Pat Meenan, 2015-01-27 21:19:41]

I made the latest changes in 2 patchsets.  The first one added some class
comments for the renderer classes that were missing comments.

The second patchset was a pretty big rename where I went through and cleaned up
the file names and class names of everything to more accurately represent what
they actually do.

[mmenke, 2015-01-30 15:32:54]

LGTM, sorry for slowness, took a few days off.

[Pat Meenan, 2015-01-30 16:01:00]

pmeenan@chromium.org changed reviewers:
+ brettw@chromium.org

[Pat Meenan, 2015-01-30 16:01:01]

brettw@chromium.org: Could you PTAL at the component rename (owners, deps, etc)?
Already got sign-off on the actual net interface rename from the net team but I
need to change the owners, etc as a result.

[brettw, 2015-01-30 18:56:46]

LGTM, just did a spot check of build files.

[Pat Meenan, 2015-01-30 19:00:15]

The CQ bit was checked by pmeenan@chromium.org

[commit-bot: I haz the power, 2015-01-30 19:01:10]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/848303005/80001

[Pat Meenan, 2015-01-30 19:02:21]

The CQ bit was unchecked by pmeenan@chromium.org

[Pat Meenan, 2015-01-30 20:42:29]

The CQ bit was checked by pmeenan@chromium.org

[commit-bot: I haz the power, 2015-01-30 20:43:38]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/848303005/100001

[commit-bot: I haz the power, 2015-01-30 22:00:29]

Committed patchset #6 (id:100001)

[commit-bot: I haz the power, 2015-01-30 22:01:26]

Patchset 6 (id:??) landed as
https://crrev.com/ed4b6f8b7392eb64fc664aa49f2627ecb5fdc073
Cr-Commit-Position: refs/heads/master@{#314001}