[IAEP] [Sugar-devel] [GSoC] Sugar Browser

[Tomeu Vizoso]

On Sun, Mar 21, 2010 at 23:25, 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.

The extent up to which xulrunner will be supported by Mozilla as an
embeddable engine is the most important point, IMHO. But up to now we
only have rumours and speculation. Could someone add a reference to a
clear statement or ask someone at Mozilla?

Ubuntu's position on this is explained here, though I would prefer
something clearer:

https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/

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

When comparing performance, we need to compare apples to apples, which
can be a lot of work. One way to move forward regarding this is to
make a simpler Browse comparable in functionality to the current Surf
and measure that.

> While gecko has superior extendability (XUL
> extensions), Browse isn't compatible with Firefox extensions, so anything
> would need to be rewritten anyway.

Google gears runs unmodified on Browse. Extensions that depend on
Firefox interfaces will only run on Firefox, but there are lots of
extensions that only use Xulrunner interfaces.

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

As pointed out above, I think the maintainability issue is the most
important here. While we have reasons to fear about Mozilla in this
regard, we should act on more final information.

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

In summary, I think this is a very interesting proposal, thanks for
bringing it up again.

Regards,

Tomeu