DevTools: migrate APU from dedicated commands to the inspector protocol.

DevTools: migrate APU from dedicated commands to the inspector protocol.

BUG=
TEST=

[Erik does not do reviews, 2011-01-10 20:07:21]

will this enable us to get rid of --enable-extension-timeline-api?

On Mon, Jan 10, 2011 at 12:02 PM, <pfeldman@chromium.org> wrote:

> http://codereview.chromium.org/6119005/
>

[jaimeyap, 2011-01-10 20:42:33]

On Mon, Jan 10, 2011 at 3:07 PM, Erik Kay <erikkay@chromium.org> wrote:

> will this enable us to get rid of --enable-extension-timeline-api?


I don't think so. I believe that flag exists to activate the
ExtensionDevToolsManager, which installs the extentions/devtools bridge that
routes DevTools messages to a chrome extensions API.

Would anyone object to making the wiring up the ExtensionDevToolsManager a
part of enabling the experimental extension APIs? Then we could drop
--enable-extension-timeline-api and instead require users to use the "more
standard"
--enable-experimental-extension-apis<http://code.google.com/chrome/extensions/experimental.html>.
Still requires a flag, but at least it isn't a special cased flag.


>
>
> On Mon, Jan 10, 2011 at 12:02 PM, <pfeldman@chromium.org> wrote:
>
>> http://codereview.chromium.org/6119005/
>>
>
>

[pfeldman, 2011-01-10 20:55:54]

On Mon, Jan 10, 2011 at 11:42 PM, Jaime Yap <jaimeyap@google.com> wrote:

>
> On Mon, Jan 10, 2011 at 3:07 PM, Erik Kay <erikkay@chromium.org> wrote:
>
>> will this enable us to get rid of --enable-extension-timeline-api?
>
>
> I don't think so. I believe that flag exists to activate the
> ExtensionDevToolsManager, which installs the extentions/devtools bridge that
> routes DevTools messages to a chrome extensions API.
>
> Would anyone object to making the wiring up the ExtensionDevToolsManager a
> part of enabling the experimental extension APIs? Then we could drop
> --enable-extension-timeline-api and instead require users to use the "more
> standard"
--enable-experimental-extension-apis<http://code.google.com/chrome/extensions/experimental.html>.
> Still requires a flag, but at least it isn't a special cased flag.
>
>

I would object. I'd much rather get rid of it as a whole and make timeline
instrumentation a part of DevTools (or Chrome) extension API. As you know,
we are working on devtools extensibility in two directions:

- enabling devtools extensions
- enabling alternate front-ends for devtools

Making SpeedTracer a devtools extension would be trivial: API surface it
needs is tiny. Making it an alternate front-end is also possible (using
--remote-debugging-port). We are currently working on making both extension
API and remote protocol stable. Given that we have two solid stories for
extensibility, I don't think we need a third ad-hoc way. I think it played a
good role in the SpeedTracer's success and fast delivery, but I'd say it is
time to move on and expose solid standards.

Thanks
Pavel


>
>>
>> On Mon, Jan 10, 2011 at 12:02 PM, <pfeldman@chromium.org> wrote:
>>
>>> http://codereview.chromium.org/6119005/
>>>
>>
>>
>

[jaimeyap, 2011-01-10 21:12:29]

On Mon, Jan 10, 2011 at 3:55 PM, Pavel Feldman <pfeldman@chromium.org>wrote:

>
>
> On Mon, Jan 10, 2011 at 11:42 PM, Jaime Yap <jaimeyap@google.com> wrote:
>
>>
>> On Mon, Jan 10, 2011 at 3:07 PM, Erik Kay <erikkay@chromium.org> wrote:
>>
>>> will this enable us to get rid of --enable-extension-timeline-api?
>>
>>
>> I don't think so. I believe that flag exists to activate the
>> ExtensionDevToolsManager, which installs the extentions/devtools bridge that
>> routes DevTools messages to a chrome extensions API.
>>
>> Would anyone object to making the wiring up the ExtensionDevToolsManager a
>> part of enabling the experimental extension APIs? Then we could drop
>> --enable-extension-timeline-api and instead require users to use the "more
>> standard"
--enable-experimental-extension-apis<http://code.google.com/chrome/extensions/experimental.html>.
>> Still requires a flag, but at least it isn't a special cased flag.
>>
>>
>
> I would object. I'd much rather get rid of it as a whole and make timeline
> instrumentation a part of DevTools (or Chrome) extension API. As you know,
> we are working on devtools extensibility in two directions:
>
> - enabling devtools extensions
> - enabling alternate front-ends for devtools
>
> Making SpeedTracer a devtools extension would be trivial: API surface it
> needs is tiny. Making it an alternate front-end is also possible (using
> --remote-debugging-port). We are currently working on making both extension
> API and remote protocol stable. Given that we have two solid stories for
> extensibility, I don't think we need a third ad-hoc way. I think it played a
> good role in the SpeedTracer's success and fast delivery, but I'd say it is
> time to move on and expose solid standards.
>
>
To clarify. You are suggesting removing the DevTools extensions bridging and
then have SpeedTracer connect via the remote debugging port. This seems
pretty clean to me.

I would just want to make sure we co-ordinate sufficiently that we stage the
changes in such a way that people aren't broken, and we can update user
documentation (they will now need to use --remote-debugging-port). There are
also some subtle details like ensuring the user experience doesnt change.
How do we map a Tab in chrome extensions land, to a Tab in remote Devtools
protocol land?


> Thanks
> Pavel
>
>
>>
>>>
>>> On Mon, Jan 10, 2011 at 12:02 PM, <pfeldman@chromium.org> wrote:
>>>
>>>> http://codereview.chromium.org/6119005/
>>>>
>>>
>>>
>>
>

[yurys, 2011-01-11 12:26:49]

LGTM