ishe...@chromium.org
unread,May 16, 2012, 1:57:22 PM5/16/12Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to j...@chromium.org, ste...@chromium.org, chromium...@chromium.org, m...@chromium.org, j...@chromium.org
(LGTM)
On 2012/05/16 14:47:31, Jesse Doherty wrote:
> On 2012/05/15 22:11:17, Ilya Sherman wrote:
> > I still think this might be more appropriate as a member of the
MetricsService
> > class. I'm not sure if there's someone who'd qualify as an "owner"
of the
> > BrowserProcess code, who could comment on this
> FWIW putting it here was a recommendation from dominich@.
Fair enough, I'm ok with keeping it here if that seems better than
having it be a member of the MetricsService -- I don't have any better
suggestions on where it might live.
On 2012/05/16 14:33:49, SteveT wrote:
> Does the functionality in VariationsService have much to do with the
> functionality in MetricsService? In fact, I don't think MetricsService
actually
> uses the VS at all.
> I agree with you that we should avoid hanging more stuff off the
browser process
> if possible, but is it worth introducing a new member to the class
just for the
> class to hold on to it, without actually utilizing it?
Agreed, the MetricsService does not use the VariationsService directly.
However, it does have the same lifetime, and is generally what I think
of as the "central dispatcher" for all things related to metrics. It's
certainly not a perfect fit; my main motivation was to avoid adding yet
another dependency to the core browser process files.
> It seems like the VS has more to do with the FieldTrialList than
MetricsService,
> but I'm also reluctant to put it in there :)
Yeah, if the FieldTrialList code wasn't in base/, that would almost
certainly be the right place to store this... but given that it *is* in
base/, that wouldn't really work.