[Webkit-unassigned] [Bug 51364] Web Inspector: Remote Web Inspector - Cross Platform InspectorServer

[bugzilla-daemon at webkit.org]

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





--- Comment #54 from Pavel Feldman <pfeldman at chromium.org>  2011-01-27 13:08:11 PST ---
(In reply to comment #53)
> (In reply to comment #50)
> > (From update of attachment 80254 [details] [details])
> > View in context: https://bugs.webkit.org/attachment.cgi?id=80254&action=review
> > 
> > > Source/WebCore/inspector/InspectorServer.cpp:1
> > > +/*
> > 
> > My biggest concern is that this class lives in the WebCore. In Chromium, we can't do page discovery from within the WebCore and we also can't open listen socket from there.
> 
> The main advantage of having InspectorServer be in WebCore was to share some of the
> code for setting up connections and disallowing remote inspection. For example, the
> upgrade request paths "/devtools/page/<num>", listing page "/", disallow for private
> browsing, existing inspectors, etc. But that isn't too much code, and maybe I could
> come up with a way to share it. Suggestions are appreciated.
> 

Not sure I follow. But the way I understand it, I disagree. I think that page discovery is very browser-specific. Embedded devices that have single tab will do it their way, multi-tab browsers, the other. We don't have to standardize upon /devtools/page/<num> as long as discovery schema is shared. Furthermore, I am not sure we need to share it up front. My point here is that the less constraints we add, the wider protocol adoption is.

> > What is it going to be like in WebKit2? I was thinking that we implement it a bit differently:
> > - WebCore (or WebKit/cf) contains code that can be reused by the platforms in order to support HTTP/WebSocket server infrastructure
> > - WebKit layer instantiates it and pipes messages to the corresponding InspectorController instance.
> 
> Unfortunately I don't know much about the cross platform setups (Chromium and WebKit2).
> It sounds like to ensure there really is only 1 InspectorServer it should be in the WebKit layer.
> As for WebKit2, I'd be interested how other singletons, like the PageCache work.

I can tell you how I am seeing it:
Pre-upgrade:
- HTTP server socket implementation lives in the browser (at least in WebKit)
- Static files are served by the WebKit in a platform-specific, tab-agnostic manner. Only WebKit knows where the files are located. Mobile device can even redirect to a web-hosted version of matching front-end version.
Post-upgdate:
- WebKit exposes thin remote debugging API that wraps InspectorController's API. The latest vision is that InspectorController exposes API that is only used by WebKit (further exposed by WebKit to its clients). InspectorController's API soon will be connect, disconnect and dispatchMessageFromFrontend. Only tab-specific messages are reaching WebCore. They are already cracked payloads of the transport messages.

Such a layered structure allows us to be non-websocket bound (the standard is changing again). Imagine serving InspectorBackend that would use long GET instead of websocket (or any other standard). It also leaves a lot of flexibility for the platform owners.

Now the question is how we could make your nice WebSocket code reused between platform vendors and how much of the InspectorServer goodness we would like to reuse.

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