Hi Brent, Sure. The goal of the debugger API is to allow client apps to create their own Javascript debugger as part of their browser. This isn't possible at the moment because the API is private, and hence you need to build the debugger code as part of Webkit to be able to access the header files. What I particularly do NOT want to have to do, is supply a special patched version of webkit to users of my own framework, that uses JavascriptCore as it's scripting language.
Without trying to get ahead of the discussion, I was going to try just sticking copies of the relevant header files in my own project, and hoping that the needed symbols aren't stripped out of the lib. If that works, then things aren't too painful for me. It'll break if and when the private APIs change, but hey, that's what I get for using a private API... If the symbols have been stripped, then that WILL be painful to manage. I can't use the current inspector infrastructure because my application doesn't use webkit - think node.js (except it's scripting a custom graphics stack, not server-side code). We're running on a set top box, and don't even have a mouse available anyway... Alli On 14 juin 2011, at 19:44, Brent Fulgham wrote: > Can you share the goals of this external API, and why the existing > inspector infrastructure is not sufficient? > > Maybe if we better understood your goals, a suitable approach could be > found that satisfied your goals without running afoul of Oliver's > concerns. > > -Brent _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
