[IAEP] [GSoC] Sugar Browser

[Peter Robinson]

On Sun, Mar 21, 2010 at 10:25 PM, Lucian Branescu
<lucian.branescu at gmail.com> wrote:
> 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.

I think that is a long way in the future. A lot of interfaces use
xulrunner and as far as I'm aware its not going anywhere. The XPCom
bit I'm not so sure about. At the moment the only thing that's been
dropped out is pyxpcom which is still supported and developed as an
external package. It works fine and is packaged as part of Fedora 13.

> 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?)

Bundling xulrunner isn't an option that will be support in Fedora or
SOAS. In Fedora xulrunner is well maintained with an active team of
people fixing issues.

> 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.

While the current webkit is faster its no where near as capable and
has issues on numerous sites the current firefox is also a lot fast
than its predecessors. The 3.6.3 release of firefox (and corresponding
release of xulrunner) will have support for OOPP (Out of Process
Plugins) which will also make it more stable and fast. There's also
massive improvements being made on I/O which will speed things up on
the XO. In SOAS-2 when I upgraded my XO from the previous official
olpc release i saw massive improvements in the speed on Browse.

> 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.

So does firefox and xulrunner. It has the backing of both Nokia and
Intel in their mobile devices and is being actively ported to Android
and other mobile platforms so it shows there's a commitment to speed.
I don't think the point above is really relevant to the discussion.

> 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.

I'm not really one to comment on APIs.

Peter