(disclaimer: I am not currently employed by a browser vendor, but frequently contribute to WebKit’s Inspector)
It would be constructive to talk more about the longer term devtools strategy and architecture for Servo’s browser. Maybe at a future work week, folks can hash out some ideas in a higher-bandwidth medium. I’d be up for that. I think jdm's proposal is to use Firefox devtools to debug Servo as a remote debugging target. This will probably be how things must be done for quite a long time, since there’s a lot of DOM to implement before Servo could self-host the devtools [1]. This has the upside of reusing most of the protocol design and UI work, but the devtool frontend may not play well with a mostly-unimplemented browser. (In contrast, WebKit inspector works on many versions as well as JS-only contexts, so it’s designed to provide feature degradation.) As for the protocol: it makes sense to reuse the JS debug protocol since a lot of effort was put into it, and Servo is using the exact same JS engine. For other things (DOM, CSS, Profiler, etc), I recommend *not* cargo-culting existing protocols, at least in the long term. Many (most?) of them have a number of big and small imperfections that are now cast in stone. At the least, ask around for some postmortem thoughts; you’ll likely get an earful as to whether it’s working as intended. I haven’t seen RemoteDebug before, but at a cursory look, it seems like the union of everyone’s bad design choices. The idea would have infinitely more luck as an abstraction/polyfill library that external editors can use. There are compelling technical reasons why non-Chrome browsers don’t just use whatever Chrome put in their devtool protocol. [1] In any case, a self-hosted devtools should be in a separate process, so remote protocol-first is the only feasible option IMO. On Jul 5, 2014, at 4:42 PM, David Bruant <bruan...@gmail.com> wrote: > Hi, > > I read something about devtools in recent meeting notes [1]. > I don't know to which extent it will be useful, but I wanted to share the > RemoteDebug initiative [2]. There might be things that can be pulled out from > this project. > > David > > [1] https://github.com/mozilla/servo/wiki/Meeting-2014-06-23#devtools > [2] http://remotedebug.org/ > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
