DevTools: remove support for legacy remote debugger

DevTools: remove support for legacy remote debugger.

DevTools remote debugging protocol supersedes the legacy protocol and old implementation should be removed.

BUG=104625
TEST=Existing tests

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=111540

[pfeldman, 2011-11-22 09:15:26]

lgtm

Do you really think we can get away with it? :)

[yurys, 2011-11-22 09:48:32]

On 2011/11/22 09:15:26, pfeldman wrote:
> lgtm
> 
> Do you really think we can get away with it? :)

I'll wait for response from the possible clients of the legacy protocol before
landing this change. Sooner or later we need to delete this code. Now it blocks
my work on the DevTools content API and it feels like a good point to do the
clean-up. 

Java DevTools seems to already work fine over the new protocol. Peter, can you
confirm that?

I've heard that Speed Tracer team already has a patch which migrates their
extension to the new protocol. Kelly, what are your plans on this front?

I have my doubts wrt ExtensionPortsRemoteService, if there are any clients of
that functionality we should expose it by means of the new protocol. Stephane,
you added this code a while back, could you look at this change and speak up if
removing ExtensionPortsRemoteService would break anything?

I'm not aware of other clients that depend on the legacy protocol. Pavel, do
you?

[pfeldman, 2011-11-22 11:53:11]

> I've heard that Speed Tracer team already has a patch which migrates their
> extension to the new protocol. Kelly, what are your plans on this front?

This change should not affect SpeedTracer.

[Kelly Norton, 2011-11-22 12:10:59]

I'm planning to release a speed tracer the moment the new API leaves
experimental. Unfortunately, I can't release with experimental due to
restrictions in the web store. Can our existing API remain available until
the experimental flag is lifted on the new API?
On Nov 22, 2011 6:53 AM, <pfeldman@chromium.org> wrote:

> I've heard that Speed Tracer team already has a patch which migrates their
>> extension to the new protocol. Kelly, what are your plans on this front?
>>
>
> This change should not affect SpeedTracer.
>
>
http://codereview.chromium.**org/8635005/<http://codereview.chromium.org/8635...
>

[pfeldman, 2011-11-22 12:20:36]

We should be able to do that. In the meanwhile, can we consider adding
SpeedTracer into the gallery although it is experimental? It sounds weird that
it is legal to keep extension that uses proprietary unpublished API and requires
a command line flag in the gallery, but is illegal to keep the one requiring
experimental API... It would be great if we could migrate ST to the new API and
deprecate timeline API independently.

[sdoyon, 2011-11-22 16:31:44]

On Tue, 22 Nov 2011, yurys@chromium.org wrote:

> I have my doubts wrt ExtensionPortsRemoteService, if there are any clients of
> that functionality we should expose it by means of the new protocol. 
> Stephane,
> you added this code a while back, could you look at this change and speak up 
> if
> removing ExtensionPortsRemoteService would break anything?

I use it, as an accessibility bridge, for debugging when developing on 
CWS. Some of the Toolbar and ChromeFrame folks sniffed around this stuff 
at some point but that was a long time ago. I will admit it's quite 
possible this has a user count of 1 (myself) at this point. Although I 
will feel somewhat stranded without this. What would it take to plug 
something equivalent in that new protocol?

[Kelly Norton, 2011-11-22 17:00:37]

If we can find a way to make it happen, I'm happy to put Speed Tracer into
the gallery with experimental API use. I made the same case that you are
making a while back and everyone agreed that it would be better to have it
using experimental than having weird instructions about adding a command
line flag. However at the time, there was no option to allow apps in the
gallery to have the experimental API bit raised. I even looked at moving
Speed Tracer out of the gallery, but the path to do that didn't look good
and I was hoping to just hang on long enough for the new API to come out of
experimental.

So if we can find a way to get Speed Tracer published with experimental API
usage, I'll very happily start getting a build ready.

On Tue, Nov 22, 2011 at 7:20 AM, <pfeldman@chromium.org> wrote:

> We should be able to do that. In the meanwhile, can we consider adding
> SpeedTracer into the gallery although it is experimental? It sounds weird
> that
> it is legal to keep extension that uses proprietary unpublished API and
> requires
> a command line flag in the gallery, but is illegal to keep the one
> requiring
> experimental API... It would be great if we could migrate ST to the new
> API and
> deprecate timeline API independently.
>
>
>
http://codereview.chromium.**org/8635005/<http://codereview.chromium.org/8635...
>



-- 
If you received this communication by mistake, you are entitled to one free
ice cream cone on me. Simply print out this email including all relevant
SMTP headers and present them at my desk to claim your creamy treat. We'll
have a laugh at my emailing incompetence, and play a game of ping pong.
(offer may not be valid in all States).

[Peter Rybin, 2011-11-22 17:03:23]

Yury,

maybe it's still technically possible to gather statistics for this
protocol usage?

Peter


2011/11/22  <yurys@chromium.org>:
> On 2011/11/22 09:15:26, pfeldman wrote:
>>
>> lgtm
>
>> Do you really think we can get away with it? :)
>
> I'll wait for response from the possible clients of the legacy protocol
> before
> landing this change. Sooner or later we need to delete this code. Now it
> blocks
> my work on the DevTools content API and it feels like a good point to do the
> clean-up.
>
> Java DevTools seems to already work fine over the new protocol. Peter, can
> you
> confirm that?
>
> I've heard that Speed Tracer team already has a patch which migrates their
> extension to the new protocol. Kelly, what are your plans on this front?
>
> I have my doubts wrt ExtensionPortsRemoteService, if there are any clients
> of
> that functionality we should expose it by means of the new protocol.
> Stephane,
> you added this code a while back, could you look at this change and speak up
> if
> removing ExtensionPortsRemoteService would break anything?
>
> I'm not aware of other clients that depend on the legacy protocol. Pavel, do
> you?
>
> http://codereview.chromium.org/8635005/
>

[jam, 2011-11-22 18:08:25]

lgtm

In general, I agree that we just have to bite the bullet and get rid of this
deprecated API since it has a maintenance cost of carrying it (especially with
the Content API work). Chrome, like Google web properties, will have users for
any deprecated  API that we want to remove. Given that the usage is very low,
and we have another alternative (even if it's not 100% compatible), I think we
should remove this, the sooner the better. The more we wait, the more users that
will find this, and also the more work we have to do to support it.

[jam, 2011-11-22 18:09:11]

On 2011/11/22 18:08:25, John Abd-El-Malek wrote:
> lgtm
> 
> In general, I agree that we just have to bite the bullet and get rid of this
> deprecated API since it has a maintenance cost of carrying it (especially with
> the Content API work). Chrome, like Google web properties, will have users for
> any deprecated  API that we want to remove. Given that the usage is very low,
> and we have another alternative (even if it's not 100% compatible), I think we
> should remove this, the sooner the better. The more we wait, the more users
that
> will find this, and also the more work we have to do to support it.

As for the extension, I think there's already a workaround: hosting it
externally until the API is not experimental.

[yurys, 2011-11-23 16:55:35]

On 2011/11/22 16:31:44, sdoyon wrote:
> On Tue, 22 Nov 2011, mailto:yurys@chromium.org wrote:
> 
> > I have my doubts wrt ExtensionPortsRemoteService, if there are any clients
of
> > that functionality we should expose it by means of the new protocol. 
> > Stephane,
> > you added this code a while back, could you look at this change and speak up

> > if
> > removing ExtensionPortsRemoteService would break anything?
> 
> I use it, as an accessibility bridge, for debugging when developing on 
> CWS. Some of the Toolbar and ChromeFrame folks sniffed around this stuff 
> at some point but that was a long time ago. I will admit it's quite 
> possible this has a user count of 1 (myself) at this point. Although I 
> will feel somewhat stranded without this. What would it take to plug 
> something equivalent in that new protocol?
> 

The new remote debugging capabilities are described at
http://code.google.com/chrome/devtools/docs/remote-debugging.html 
The debugger client may use either WebSocket connection or
chrome.experimental.debugger extension API as a transport. This currently allows
connecting to the browser tabs but it shouldn't be hard to extended with
extension background pages.

We'll be glad to help you migrate to the new protocol but we need more details
to better understand your use cases and what functionality is missing.