[Webkit-unassigned] [Bug 29312] New: reorganize debug target API

[bugzilla-daemon at webkit.org]

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

           Summary: reorganize debug target API
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Web Inspector
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: pmuellr at yahoo.com
                CC: timothy at hatcher.name, aroben at apple.com,
                    kmccullough at apple.com, pfeldman at chromium.org


See bug 27514, comment 23 :

----- start clip -----

> +    WebInspector.console._evalInInspectedWindow(expression, appendResult.bind(this, expression, i));
> 
> You should make _evalInInspectedWindow public. I would recomend moving it to
> inspector.js can calling it WebInspector.evalInInspectedWindow. That is where
> it should have been all along.

I agree this API needs to be made public and moved somewhere else.  But I'd
like to do it in a separate patch:

...

- I'd like to actually step back and see if we can find a good home for all
these target-introspective APIs.  Putting it just on WebInspector itself
probably doesn't make too much sense - perhaps a new class called TargetMirror
or something? 

----- end clip -----

That's me wondering if we should put all of these target-related APIs in one
place.  Things like:

- eval against global ( doEvalInWindow() )
- eval against global or currently selected stack frame (what
_evalInInspectedWindow() does)
- getProperties(), setPropertyValue from InjectedScriptAccess
- ObjectPropertyProxy() and ObjectProxy() from WebInspector

On a related note, there seems to be some interest around for remote debug
APIs; a colleague at work has set up a google group
http://groups.google.com/group/webdebugprotocol (not terribly active at the
moment), Google has some kind of remote debug API for Chrome tied into an
Eclipse front end -
http://blog.chromium.org/2009/08/google-chrome-developer-tools-for.html .

Not quite ready to suggest that Drosera be revived (if it's even dead, not
sure), but it might be useful to start thinking in terms of the APIs that
developers will be needing for building debuggers in general, so we can start
thinking about some common capabilities, lingo, etc.  In the future, this may
allow developers more choice in development tooling, as well as potentially
allow reuse of the significant investment already made, and to be made, in Web
Inspector.

I'll also note that I have asked up on the es-discuss mailing list about
whether the ECMAScript standards group would be interested in looking at
standardizing on debug APIs, and received positive feedback.

For some generalist backgrounder material, check out the Mirrors paper:
http://bracha.org/mirrors.pdf

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