[Sugar-devel] Sugar-devel Digest, Vol 17, Issue 49

[vijit singh]

---------- Forwarded message ----------

> From: Walter Bender <walter.bender at gmail.com>
> To: Lucian Branescu <lucian.branescu at gmail.com>
> Date: Sun, 21 Mar 2010 21:10:59 -0400
> Subject: Re: [Sugar-devel] [GSoC] Sugar Browser
> On Sun, Mar 21, 2010 at 8:27 PM, Lucian Branescu
> <lucian.branescu at gmail.com> wrote:
> > On 22 March 2010 00:12, Benjamin M. Schwartz <bmschwar at fas.harvard.edu>
> > wrote:
> >>
> >> Lucian Branescu wrote:
> >> > 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.
> >>
> >> I'm not willing to accept this as proven.  As for faster, see
> >> http://weblogs.mozillazine.org/bz/archives/020434.html
> >>
> >> As for memory usage, see
> >> http://dotnetperls.com/chrome-memory
> >
> > Of course Chrome usage is much higher. Chrome has at least one process
> for
> > each tab.
> > Safari is also a wreck, especially on Windows.
> >>
> >> Webkit may be faster (although... with which javascript engine? on what
> >> graphics hardware? with which bookmarks/awesomebar system?) but I don't
> >> think it's so obvious.  Previous comparisons on the XO have been deeply
> >> flawed because Gecko was scaling up all fonts and images, while Webkit
> was
> >> not.
> >
> > The test I have done both on OS X and soas have shown webkit to be far
> > superior in execution speed and still superior in memory usage for
> > benchmarks. These weren't entirely relevant, so I will do another set of
> > benchmarks that are more relevant to XO usage (with firefox 3.6).
> > Here are my old results:
> > http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20osx.txt
> > http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20soas.txt
> > http://dl.dropbox.com/u/317039/webkit%20vs%20gecko%20winxp.txt
> >>
> >> > 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.
> >>
> >> This sounds like an argument for staying with Gecko and adopting
> >> Greasemonkey and Jetpack.
> >
> > It's an argument for not really needing Gecko. Both could be implemented
> on
> > Webkit.
> >>
> >> > Second, webkit is being used by a lot of projects and has the backing
> of
> >> > several companies.
> >>
> >> Gecko is far more widely deployed (~30% of all internet users).
> >
> > The arguments other people have given to me have to do with how many
> > projects use it (maintained by many companies/communities).
> >>
> >> > Furthermore, it is packaged more consistently across
> >> > platforms/distributions.
> >>
> >> I'm not sure what this means, but it doesn't seem critical.
> >
> > Xulrunner tends to have many patches applied by distros. Webkit doesn't.
> >>
> >> > 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 certainly not going to complain about an abstraction layer of this
> >> sort.  As I've said before, I think a lot of developers would enjoy an
> >> "engine-agnostic" browser widget.
> >>
> >> --Ben
> >>
> >
> >
> > _______________________________________________
> > Sugar-devel mailing list
> > Sugar-devel at lists.sugarlabs.org
> > http://lists.sugarlabs.org/listinfo/sugar-devel
> >
> >
>
> While performance differences might be somewhat interesting, the fact
> that tests tend to be inconclusive suggests it is not a compelling
> reason to choose one over the other. I think one point that Lucian
> made is being lost in the discussion: maintainability. Is a
> webkit-based browser going to be easier to maintain in the near to
> long term?
>
> -walter
>
> --
> Walter Bender
> Sugar Labs
> http://www.sugarlabs.org
>
>
Yes, surely maintainability over the long term should be a major concern in
making any decision. I think the fact that Mozilla might lose support for
XPCOM ( if that's true) is something that matters. However, developing the
webkit-based browser during gsoc( to explore the possibilities) along with
maintaining browse is what might be a good solution.

Regards,
VIJIT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20100322/5a38520a/attachment.htm