[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 #14 from Pavel Feldman <pfeldman at chromium.org>  2010-02-17 13:33:24 PST ---

> Just to make sure I understand what you are suggesting. You are saying that it
> is OK to provide alternate implementations of the interface provided by the
> script proxy object or by providing alternate implementations of
> ScriptFunctionCall. 
> 
> The former implies that the communication channel to the UI needs to be
> implemented in Javascript by a script proxy object that implements the same
> interface as WebInspector from WebCore/inspector/front-end/inspector.js.
> 
> The latter (subclassing ScriptFunctionCall) seems like a bigger change to
> WebCore but enables more choice of implementation language for the debugger
> communication protocol. But I can envision how to make this work.
> 
> I'm a little curious why the designated externizable inspector API is one that
> doesn't have any declaration apart from its implementation, rather than one of
> the ones defined in a C++ header file or a .idl file.

First of all, ScriptValue/Object/FunctionCall are inspector's properties. They
are only used in Inspector code, we can change them. The point I was trying to
make was that ScriptFunctionCall is essentially a container for a message. It
is an array of ScriptValues that can be serialized into a JSON string. We could
change InspectorFrontend to receive a delegate with interface 

InspectorFrontendDelegate {
    void dispatch(String)
}

and do serialization in the InspectorFrontend. It is just that we did not want
to do that because we wanted to stay on the JS object ground for in-process
case efficiency. In Chromium, we pass a frontend proxy object that does exactly
this - it serializes this JS value using JSON.stringify and sends it to the
front-end over the wire as string. So we already have an abstraction you are
looking for, no need to subclass.

Here is how I see adding an HTTP server into the WebCore picture:
1. InspectorController receives a command to open the front-end.
2. This command is going to the emedded via the InspectorClient interface and
initiates one of the following:
- in-process front-end page opening in WebKit or
- server setup or a device or 
- chrome dev tools init in case of WebKit/chromium.
3. InspectorController awaits for WebKit to report that the front-end is ready.
WebKit notifies InspectorController and passes it a front-end delegate. This
delegate basically has a single method: "dispatch(String message);".
InspectorFrontend serializes ScriptValue into JSON and pushes resulting string
into the host's front-end representative. As mentioned above, this could be a
two step thing (frontend object proxy -> frontend delegate) for in-process
efficiency of WebKit.
4. In case of HTTP server, this object is wrapped with <script> and pushed to
the client.
5. Incoming messages are dispatched from JSON against InspectorBackend binding
via the injected script.

HTTP message format should also be defined by the WebCore, so there should
be single HTTP server located beside InspectorController code. We should come
up with something browser and Eclipse SDK would equally like. It might be that
<script> with payload is not the best message format.

It is important that in the beginning, there is always inspector's front-end
instance on the other end of this communication. It allows us not to expose
interchange protocol to third parties for now. If you are interested in the
protocol to be exposed and maintained, please file a separate bug with the
request.

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