No subject

1) Performance tests of recent webkit and xulrunner on XOs and other
hardware SoaS runs on would be useful, paying close attention to
real-world relevance.

2) Regardless of the results of the benchmark, it would be useful to
write an abstraction layer over hulahop/pywebkitgtk/whatever would be
used for embedding Mozilla 2. It should allow the Sugar browser the
ability to switch between engines, if not at runtime at least with
very little effort.

On 22 March 2010 08:39, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
> 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
>