Changes between Version 2 and Version 3 of ProposedWebInspectorRearchitecting


Ignore:
Timestamp:
Sep 11, 2008 10:45:36 AM (14 years ago)
Author:
ojan@chromium.org
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ProposedWebInspectorRearchitecting

    v2 v3  
    55The long-term goal is to have a well-defined API that speaks JSON between the Inspector's JS and the underlying representation of the page. At first, that underlying representation of the page will be written entirely in JS and access the inspected page's DOM directly. Eventually, we can start moving appropriate bits to C++, or in Chromium's case IPC, as necessary.
    66
     7The eventual stack will look something like this:
     8
     9Inspector JS
     10-----------------------------
     11API Shim JS
     12-----------------------------
     13InspectorController C++ Give this a generic client (InspectorControllerClient?) that Chromium can implement as IPC.
     14-----------------------------
     15Possibly an IPC layer
     16-----------------------------
     17C++ Receives calls from the InspectorControllerClient
     18-----------------------------
     19Inspected Page's JS
     20
    721= APIs to implement =
    822We'll put all these as objects on the InspectorController.
    923
    1024== Console ==
     25
    1126InspectorController.Console
    1227
    1328== Profiler ==
    14 InspectorController.Profiler
     29
     30InspectorController.Profiler.?
    1531
    1632== Resources ==
    17 InspectorController.Resources
     33
     34InspectorController.Resources.?
    1835
    1936== DOM ==
     37
    2038InspectorController.DOM.getChildren(node)
     39
    2140InspectorController.DOM.getParent(node)
    2241
    23 node here is a JS object that has a one-to-one mapping with the DOM node in the page. E
     42node here is a JS object that has a one-to-one mapping with the DOM node in the page. Everything above this API layer only knows about the node JS object. Somewhere in the implementation of the API there needs to be a mapping. Initially, it can just be an in JS map. Eventually, the map will probably move to C++, at the very least it will for the IPC-based version.
     43
    2444== Database ==
     45
     46InspectorController.Database.getCurrentStack() ?
     47
     48InspectorConteoller.Database.?
     49
    2550== Debugger ==
    2651
     52InspectorController.Debugger.?
     53
    2754== Miscellaneous other notes ==
     55
     56Objects viewed in the console should be snapshots (i.e. not live). In addition to matching user expectations better, this means we don't need to worry about objects on the page getting GCed. Similarly, any live objects in the debugger should not be GCable.
     57
     58For making sure the inspector has zero impact on page load times and minimal impact on memory usage we agreed on a few UI changes. Network monitoring and possibly debugging should be opt-in per-site. The console should only keep around XXX messages unless the user opts-in to keep more (all?) messages for that site. Currently, Chromium has XXX==100, but that was a relatively arbitrary decision. As a side note, the Chromium/V8 debugger is already zero cost until a debug statement is actually hit, so Chromium doesn't actually care about the debugger being opt-in.