The Chromium port of WebKit already acts very much like a headless build of WebKit owing to the Chromium sandbox, which denies the WebKit process access to most features of the system, including the GUI system.<div><br></div>
<div>The interface lives here:</div><div><a href="http://trac.webkit.org/browser/trunk/WebKit/chromium">http://trac.webkit.org/browser/trunk/WebKit/chromium</a></div><div><br></div><div>Documentation is still very sparse, but the basic idea is that the embedder must implement WebKitClient, which provides access to some of the required system services.  If you are interested, I would start by looking at the Chromium WebKit port to Linux.</div>
<div><div><br></div><div>Cheers,</div><div>-Darin</div><div><br><br><div class="gmail_quote">On Tue, Nov 17, 2009 at 6:16 AM, Sergiy Temnikov <span dir="ltr">&lt;<a href="mailto:Sergiy.Temnikov@4d.com">Sergiy.Temnikov@4d.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">



<div>
<div><font size="2"><font size="3">Hi,<br><br>We are working on a new application 
server that uses WebKit for<span> </span>server-side 
JavaScript execution (and remote JavaScript debugging<span> </span>too). However, we can not use WebKit as is 
because we <span> c</span>an not link<span> </span>with any of the GUI libraries and WebKit does. 
Instead, we compile<span> </span>just the 
JavaScriptCore part for JS execution. So my question is, are<span> </span>there any plans in the future to refactor or 
redesign WebKit to be<span> </span>more suitable for 
server environment? Would this, in your opinion,<span> 
</span>interest the WebKit community?<br>For example, the first thing we had to 
deal with is the JS debugger.<span> </span>Debugger 
interface is defined in JavaScriptCore but its implementation<span> </span>lives in WebCore. Most of the debugger&#39;s 
implementation is abstract<span> </span>except for the 
part which sends event notifications to pages and<span> 
</span>frames objects which are GUI dependent and so can not be used in a<span> </span>faceless server application. So we basically 
copied the source of the<span> </span>existing 
debugger, commented out GUI related calls and added some<span> </span>stuff to transform it into a debugger which can 
be controlled remotely<span> </span>over the network. I 
would be happy to contribute to the WebKit project<span> </span>to add a layer of abstraction to the existing 
debugger implementation<span> </span>to cut its 
dependence on GUI and move it to JavaScriptCore from<span> </span>WebCore&#39;s inspector.<br>Another example would 
be the XMLHttpRequest class implementation which<span> 
</span>exists in WebCore. In many indirect ways it depends on GUI even 
though<span> </span>it should not. As such, we can not 
simply expose it in our JavaScript<span> 
</span>environment on a faceless server. There are many other classes like<span> </span>it.<br>All in all, so far it has been great fun 
to make the WebKit code run<span> </span>on the server 
side. I just wanted to raise awareness of the needs of<span> </span>server-side developers.<br></font><font color="#888888"><br><font size="3">-Sergiy Temnikov,<br>Wakanda Server 
Architect<br>Wakanda Software</font></font></font></div>
<div><font color="#888888"></font> </div></div>
<br>_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
<br></blockquote></div><br></div></div>