<div>Some have expressed concern about Browse and its current xulrunner dependency (<a href="http://bugs.sugarlabs.org/ticket/1850" target="_blank">http://bugs.sugarlabs.org/ticket/1850</a>). To make matters even worse for the future, Mozilla plans to get rid of XPCOM at some point in favour of better JavaScript interfacing to C++ and a JavaScript ffi similar to ctypes.</div>

<div><br></div><div>Surf is an existing browser activity that uses webkit (pywebkitgtk). It is not yet on par feature-wise with Browse, but it could be extended.</div><div><br></div><div>I see a few possible ways forward, that I could work on for GSoC:</div>

<div>1) Get Browse into shape (with a bundled xulrunner?)</div><div>2) Update Surf to be on par with Browse</div><div><br></div><div>I am inclined to choose the second for a few reasons. First, current webkit is much faster and uses less memory than current gecko, which has been especially visible on XOs. While gecko has superior extendability (XUL extensions), Browse isn&#39;t compatible with Firefox extensions, so anything would need to be rewritten anyway. Userscripts (Greasemonkey) serve most needs for now and if needed, an extension API akin to Mozilla&#39;s Jetpack or Chrome&#39;s extensions could be implemented.</div>

<div><br></div><div>Second, webkit is being used by a lot of projects and has the backing of several companies. Furthermore, it is packaged more consistently across platforms/distributions.</div><div><br></div><div>Third, pywebkitgtk and hulahop have a similar API (and pywebkitgtk tries not to diverge unless necessary) and it should be possible to not depend too much on any one of them. A thin abstraction layer could be written on top to handle most differences and it should only rarely be needed to go beneath this abstraction. While this would most likely not result in a browser than can switch engines at runtime, it should make any future porting much easier.</div>

<div><br></div><div>Any thoughts on this?</div>