[Sugar-devel] Did someone say Webkit?

[Bernie Innocenti]

On Mon, 2010-04-26 at 23:29 +0100, Lucian Branescu wrote:
> This is part of why I think having an abstraction layer is more
> important than having a complete pywebkitgtk browser activity.
> 
> I would be even cooler if Read could also use this abstraction layer for epub.

Now it makes sense. As long as there's only one activity using this
abstraction layer, it wouldn't make sense to have it as a separate
module.

But careful: designing glue code of this kind is really hard. They're
really bridges with an abstract API on each side. The Linux vfs layer
would be a good example. Many iterations may be necessary to refine the
interface before it can be considered stable on both side.

These things also tend to make debugging very hard, because they
introduce 2-3 additional layers of indirection between the user
interface and the engine doing the actual work on its behalf.

To slightly reduce the overall complexity, one may think to fold hulahop
into one of the concrete browser implementations and remove most of the
excess flexibility that it delivered. Anyway, Browse appears to be the
only user of hulahop in the entire universe, so it would have been
stupid to maintain in separately.

This is of course just the personal opinion of a minimalist embedded
engineer who hates unnecessary abstractions. I'm aware that innumerable
books of mainstream software engineering encourage a diametrically
opposite approach.

In support my demodé opinion, consider that among the production-quality
browsers, only Epiphany attempted to abstract away the differences
between Mozilla and Webkit. However, after a while they decided it was
too much work for too little benefit. Eventually, they discontinued
Mozilla support.

Epiphany was trying to solve just one half of the whole problem of
mediating between multiple applications and browser engines. KDE's KPart
would be closer to what you want to do, but after several years of
struggling, the webkitpart still hasn't reached the point of usability.

That said, I'm not familiar with the details of any of the APIs in
question. It may very well be overestimating the actual complexity and
the other projects I mentioned might have just been unlucky or
mismanaged.


> On 26 April 2010 21:10, Sayamindu Dasgupta <sayamindu at gmail.com> wrote:
> > On Mon, Apr 26, 2010 at 2:18 PM, Lucian Branescu
> > <lucian.branescu at gmail.com> wrote:
> >> There already is a mostly complete pywebkitgtk activity, Surf.
> >>
> >> There has been a lot of debate on whether webkit is better than gecko
> >> for our purposes. I also plan to only support what is reasonably easy
> >> to support and let the abstraction layer be leaky.
> >>
> >> This way, the new Browse can much more easily be ported to another web
> >> engine if needed. In fact, as the abstraction layer grows more
> >> complete, Browse can be 'ported' to the rest of the abstraction layer
> >> (as opposed to AbstractBrowser+hulahop events which would be the first
> >> step).
> >>
> >
> > Something which concerns me is the relative lack of maintainer
> > activity for pywebkitgtk. For example,
> > http://code.google.com/p/pywebkitgtk/issues/detail?id=44 lists an
> > issue which was reported in December last year, and there has been no
> > feedback on it (there is a proposed patch as well). The fix for the
> > issue would help address a few crashers in Read in F-12 and above.
> > Of course, as we move to gobject-introspection and friends, this
> > should become less of a concern.
> > Thanks,
> > Sayamindu
> >
> >
> >
> >
> >> On 26 April 2010 03:20, Bernie Innocenti <bernie at codewiz.org> wrote:
> >>> On Sun, 2010-04-25 at 18:07 +0100, Lucian Branescu wrote:
> >>>> My GSoC project involves building an abstraction layer above
> >>>> pywebkitgtk/hulahop (wiki/AbstractBrowser).
> >>>>
> >>>> While the project itself isn't related, this abstraction layer and one
> >>>> of it's lower layers (i.e. pywebkitgtk) would become a dependency of
> >>>> the sugar toolkit.
> >>>
> >>> Very interesting. Would your work make it possible to switch the Browse
> >>> activity from XPCOM to Webkit?
> >>>
> >>> If there were no loss of features, would it be easier for you to switch
> >>> the Browse activty from hulahop to pywebkitgtk without developing an
> >>> abstraction framework for both?
> >>>
> >>> --
> >>>   // Bernie Innocenti - http://codewiz.org/
> >>>  \X/  Sugar Labs       - http://sugarlabs.org/
> >>>
> >>>
> >>
> >
> >
> >
> > --
> > Sayamindu Dasgupta
> > [http://sayamindu.randomink.org/ramblings]
> >
> 

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/