[Webkit-unassigned] [Bug 37306] New: Web Inspector: Stop using JavaScript Script* objects as a transport for InspectorController <=> front-end interaction.

[bugzilla-daemon at webkit.org]

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

           Summary: Web Inspector: Stop using JavaScript Script* objects
                    as a transport for InspectorController <=> front-end
                    interaction.
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Web Inspector
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: pfeldman at chromium.org
                CC: timothy at hatcher.name, joepeck at webkit.org,
                    yurys at chromium.org, loislo at chromium.org


In the light of WebKit2, we can start _now_.

1) InspectorController => front-end

Today we use JavaScript wrappers living in Script* for sending messages from
InspectorController to the front-end.
- This approach is straightforward for WebKit's in-process architecture
- We've found a solution for Chromium that uses custom dispatch implementation
and marshals the calls across the process boundary.

There are several drawbacks in this way of living:
- Inspector is running its javascript code on the inspected page (this might
affect profiling, debugging, prevents from instrumenting gc well)
- This is hacky from the multiprocess point of view: it introduces artificial
js environment.

The proposed solution is to use Chromium's value infrastructure instead of
ScriptObject / ScriptArray / ScriptValue when talking to the front-end:
- http://src.chromium.org/viewvc/chrome/trunk/src/base/values.h
- http://src.chromium.org/viewvc/chrome/trunk/src/base/json/json_writer.cc
- Replace WebInspector.dispatch's setTimeout with WebCore level async execution
for in-process version of inspector + out-of-process versions of WebKit and
Chromium will naturally provide that.

2) front-end => InspectorController

Today, we inject InspectorBackend binding into the front-end in WebKit / inject
it into utility context on the inspected page side in Chromium. Time to align
in the light of WebKit2 changes. What we should do is:
- Provide a way of marshaling InspectorBackend.* calls from the front-end to
the InspectorController across process boundary. InspectorBackend.* are only
operating primitive parameter types, are called from JavaScript environment and
should be dispatched on a native object. There is no strict need for it to be a
binding anymore should we come up with a cross-process binding that supports
primitive value types.

Two ways of solving:
- Based on the IDL, generate a dispatcher that would parse call payloads and
dispatch them on InspectorBackend native instance
Pros: Code gen approach
Cons: People might consider all idls are bindings, code gen is in perl
- Move from the IDL to a Chromium-style macro
Pros: We have some code to reuse
Cons: Macros are bad comparing to the code gen.

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