[webkit-dev] WebKit blog post proposal: Remote debugging with Web Inspector.
Pavel Feldman
pfeldman at chromium.org
Mon Aug 9 12:48:48 PDT 2010
Hi guys,
As some of you know, we are working on a remote debugging feature in Web
Inspector. There are many good reasons behind the project including the
following:
- Debugging WebKit on embedded devices
- Shaping up a good protocol for ourselves
- Introducing external SDKs on top of the protocol for IDE integrations and
alternate front-ends
We've had serialized interaction with the out-of-process inspector for quite
a while in Chromium. We were upstreaming it into WebKit and have reached an
important milestone recently: all the interaction between the inspected page
and inspector is entirely serialized on the WebKit level. All the embedder
needs to do is to implement a socket that would serve the inspector
front-end files and provide our messaging with appropriate transport.
Now this socket is likely to be platform-specific, implemented on the WebKit
and/or host browser levels. It also makes more sense to implement socket on
mobile platforms first. However, we've done a proof-of-concept
implementation in Chromium and it is now in a demoable state! See the
screencast at http://screencast.com/t/YTI2OTY4YTEt. It has Chromium nightly
to the left + WebKit nightly to the right. WebKit nightly connects remotely
to Chromium over HTTP on the port 9222 and does remote debugging including
DOM inspection, breakpoints and such. The communication is established by
means of a WebSocket. The interesting thing about the implementation is that
inspector front-end is fetched from the host browser, so that there is no
mess with protocol versioning and no need in exposing the interaction
protocol any time soon.
So I made the demo and it looked cool. I thought maybe we do a blog post on
it. The blog post would draw attention to the Web Inspector and its
progress, share the remote debugging vision with the interested parties and
would simply look cool. Front-end is working as a pure HTML5 application
(obviously full of WebKit-specific styles, but still) which is impressive.
Now the project is nowhere complete in terms of finalizing the message
format and the protocol itself, but there is no intention to expose it right
now. We'd like to let it live with fetchable front-end and mature before we
expose the protocol and commit to any level of interface support.
What do you think, is it ready for a blog post?
Thanks
Pavel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100809/e92990af/attachment.html>
More information about the webkit-dev
mailing list