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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jan 19 16:19:08 PST 2011


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





--- Comment #30 from Joseph Pecoraro <joepeck at webkit.org>  2011-01-19 16:19:07 PST ---
(In reply to comment #28)
> (From update of attachment 77066 [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.


> 2) Can we make the code more cross-platform friendly? I.e., use C++ instead of ObjC, hide the CF use inside CF-specific files, etc.

Yes, the model for that would be WebCore/platform/network/SocketStreamHandle, and
other WebSocket client code which is a C++ facade for cross platform implementations.


> 3) Is there code we should be sharing with WebCore for the WebSocket-y stuff?

Absolutely. WebCore/websockets/WebSocketChannel.h comes to mind for framing, sending
and receiving messages. Few functions are identical (`setChallengeNumber`) but
there are numerous aspects of the Web Socket server implementation in this patch that
must be kept in sync with WebCore's Web Socket client implementation. Esp with all the
changes to the Web Socket drafts. Namely the Handshake, Message Framing, and Headers.
Having these side by side in WebCore would good for all clients and might make
testing / development easier having both sides at your disposal (and could lead to
subtle bugs with other implementations).


> 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.

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



More information about the webkit-unassigned mailing list