[Webkit-unassigned] [Bug 51364] Web Inspector: Remote Web Inspector for platform/mac

[bugzilla-daemon at webkit.org]

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





--- Comment #31 from Adam Roben (aroben) <aroben at apple.com>  2011-01-20 09:05:34 PST ---
(In reply to comment #30)
> (In reply to comment #28)
> > (From update of attachment 77066 [details] [details])
> > A few general comments based on an extremely quick glance:
> 
> These are all very good comments. I'll post some feedback for each. But I think its
> pretty clear that a WebCore implementation of a WebSocket server is desired.
> 
> 
> > 1) Why is all this code up in WebKit? WebKit should ideally be a thin API layer on top of WebCore.
> 
> I think it is totally preferred. I thought about that early on, but in my haste to get a working
> version of this out and not sit on my hands, I put it into a FIXME and produced these patches.
> 
> >   Patch 3, WebKit/mac/WebInspector/WebInspectorServerConnection.mm:
> >   // FIXME: Maybe this be folded into WebCore, abstracted on top of /platform/network/SocketStreamHandle.
> >   // Moving it into WebCore would help make this maintainable and identical across platforms, as well
> >   // as making it easier to keep in sync with WebCore's client side WebSocket implementation.
> 
> A couple of other reasons I went forward with this WebKit approach were:
> 
>   1. That is what Chromium (outside of WebKit) and Qt (inside WebKit/qt) have done.
>   2. I have very little experience with cross platform code. I felt if I could get something
>      working first for Mac, it would be easier to then move / port that to WebCore, without
>      originally putting it in WebCore and potentially breaking other ports or superceeding
>      their implementations.
> 
> Stepping back, #2 could be based on false assumptions I have.

If it's important to get this landed soon, it could probably go in in its current form. But if we have a little time to spare I think it's probably worth reworking it.

We should talk with the Chromium and Qt people and see if they would be interested in sharing an implementation, if they have any requirements regarding the protocol that we aren't aware of, etc. We should be able to learn from their experience in this area, too.

> > 4) It would be nice if we could use WebKit2's CoreIPC layer for handling the IPC. Doing that would require moving CoreIPC out of WebKit2 and into some lower level (which we want to do eventually anyway).
> 
> The only IPC here goes over HTTP requests. I'm not as familiar with WebKit2 as I
> would like to be, but I'm not sure this approach would benefit. Does the CoreIPC
> layer adapt to network communication between processes, or do you mean that
> on the same machine the network could be avoided? Right now this works so that
> your browser can inspect a webview on another machine's browser (X) by "downloading"
> the Web Inspector frontend (html/css/js) from X and communicating to X via
> Web Sockets.

CoreIPC right now is all about IPC on a single machine. So I guess you should stick with your current method for now.

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