[Webkit-unassigned] [Bug 35016] Enable alternate front-ends for Web Inspector

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=35016





--- Comment #6 from Pavel Feldman <pfeldman at chromium.org>  2010-02-17 12:11:58 PST ---
(In reply to comment #5)
> Created an attachment (id=48913)
 --> (https://bugs.webkit.org/attachment.cgi?id=48913) [details]
> Qt debug agent partially implementing ChromeDevTools and V8 debug protocol
> 
> For reference: This is a patch to Qt that implements remote Web Inspector
> usage, supporting all Web Inspector functionality. It is a quick prototype and
> not stable.
> 
> It includes an HTTP server in QWebInspector that can be enabled for remote
> debug. It serves 4 information channels through the HTTP server:
> 1) Built-in resource files -- the HTML, Javascript, images, and style sheets
> composing the Web Inspector UI (original encoding)

Ok.

> 2) Asynchronous RPC to InspectorBackend via HTTP POST (encoded as JSON)

How do you deal with the calls to the InspectorFrontendHost? They are supposed
to be served on the front-end side. Are you sending those to the inspected page
side as well?

> 3) Polling for events to the frontend via HTTP POST (encoded as JSON)

Polling is not good - couldn't we just leave connection open and push client
dispatches in the <script> tags?

> 4) Dynamic resources via HTTP POST (to fetch these resources from the same
> context as the browser, in original encoding)
> 

Could you explain what this is about?

> The Inspector front-end javascript is modified to use asynchronous style when
> communicating with the back-end.
> 

It took us a while (half a year of so) to re-implement entire front-end in
order to serialize communication and make it asynchronous. What did you find
missing? The only thing I can remember of is debuggerEnabled / profilerEnabled
calls (we did not need these in Chromium). I had a pending change for that.
Anyways, I can't see your changes in the patch.

> In my current design, the remote debug agent would not require instantiating
> the Page for the Web Inspector UI nor would it require QWebInspector.
> 

Yury is currently working on a change that would abstract creation of the
inspector UI page via the InspectorClient interface. InspectorController will
basically be asking for host to open inspector somewhere and will wait while
this new front-end connects to it. Any external client (non-standard frontend)
should also be able to connect using new API. It will be a modified version of
setFrontendProxyObject.

> In terms of implementation, it was very quick because it does not change the
> messages or encodings between the backend and UI, though use of XMLHttpRequest
> caused a change to an asynchronous style of communication.

Where is this code located?


General notes:
- It would be interesting to see the server implementation and the front-end
code. It is important to remember that inspector controller does not expose its
protocol and that InspectorFrontend / InspectorBackend interfaces are private
to WebCore (should not be accessed from within WebKit).
- Talking about supporting V8 protocol over InspectorBackend, it is something
quite opposite from what we were thinking about. Instead, we were going to
establish a scope-alike protocol in the WebKit first, let it mature and move
Eclipse debugger to it.
- Eclipse ChromeDevTools / Chromium do not maintain debugging API in terms of
protocol, they provide the support in terms of the SDK instead. Every new
version of Chromium has an SDK update in case of breaking changes to the
protocol. Your implementation is clearly not ready for that.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.