[Telemetry] Clean separation between tab (public) and tab_backend (Chrome); second attempt.

[Telemetry] Clean separation between tab (public) and tab_backend (Chrome); second attempt.

First attempt here: https://chromiumcodereview.appspot.com/11819018/


BUG=None.
TEST=./run_tests in telemetry and perf for both release and system browsers.

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

[nduca, 2013-01-16 23:00:32]

lgtm but the __runtime etc stuff on the backedn is funky to me. I hope it goes
away

[dtu, 2013-01-16 23:10:39]

On 2013/01/16 23:00:32, nduca wrote:
> lgtm but the __runtime etc stuff on the backedn is funky to me. I hope it goes
> away

Mostly they're there to ensure you're Connected for all those calls. I think
that it's possible to explicitly Connect and Disconnect in SyncRequest() and
DispatchNotifications(). Actually now that I think about it, I wonder why we
didn't do that way from the start. Then you don't need these, or the weakrefs in
TabController, or a public API Disconnect() call.

[dtu, 2013-01-16 23:13:45]

On 2013/01/16 23:10:39, Dave Tu wrote:
> On 2013/01/16 23:00:32, nduca wrote:
> > lgtm but the __runtime etc stuff on the backedn is funky to me. I hope it
goes
> > away
> 
> Mostly they're there to ensure you're Connected for all those calls. I think
> that it's possible to explicitly Connect and Disconnect in SyncRequest() and
> DispatchNotifications(). Actually now that I think about it, I wonder why we
> didn't do that way from the start. Then you don't need these, or the weakrefs
in
> TabController, or a public API Disconnect() call.

I guess that requires that connecting and disconnecting are cheap, but you said
most of the overhead is in maintaining the inspector instrumentation, right? Not
in the connection.