[IAEP] [GSoC] Sugar Browser

[Lucian Branescu]

Some have expressed concern about Browse and its current xulrunner
dependency (http://bugs.sugarlabs.org/ticket/1850). 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.

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.

I see a few possible ways forward, that I could work on for GSoC:
1) Get Browse into shape (with a bundled xulrunner?)
2) Update Surf to be on par with Browse

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'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's Jetpack or
Chrome's extensions could be implemented.

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.

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.

Any thoughts on this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/iaep/attachments/20100321/294df0d6/attachment.htm