Re: Backends - was: ANNOUNCEMENT: The Future of Epiphany

["Raphael Bosshard" <raphael bosshard gmail com>]

As an end user, I don't really care which rendering engine is used to display my web pages. I just want them working and I want a web browser that is integrated into the desktop and doesn't feel like some kind of external, slapped-on piece of software. Firefox and Mozilla always felt that way, although it has been getting much better in the last two years. Still; integration could be much better.

I don't see the need to support multiple rendering engines in a
end-user browser like Epiphany. Epiphany should be easy to use, not a
power-tool for web developers. Firefox is the power-tool for
web-developers, and that's good. Epiphany I just want to be a really
good browser.

If that change to WebKit helps the developers to make use of the Gnome password facility or to use other fancy Gnome services, I heartily support it.

I find the comparison to crypto algorithms somewhat lacking; implementation of cryptological cyphers are a few kilobytes in size, with well defined input and output ports. There is little room for interpretation and thus little divergence between implementations.
A HTML rendering engine however is a different beast completely. 


So long,
Raphael

On Thu, Apr 3, 2008 at 3:57 AM, Robert Marcano <robert marcanoonline com> wrote:

On Wed, 2008-04-02 at 23:39 +0100, Alp Toker wrote:

> This is one point most developers are agreeing on. There's little value
> in pluggable web engine backends. The abstraction layers tend to limit
> functionality and increase maintenance overhead with little benefit to
> the user.

Yes, that is when you are using the engine you like the most, but not
everyone has the same needs.

I think everyone that used a crypto library saw little value on
abstracting that too, but a few years later something like this happens:

http://fedoraproject.org/wiki/FedoraCryptoConsolidation

Fedora is consolidating to only one crypto library (NSS) and read there
is work on patching every application, can we think in the future too
(if thinking on the people that need Gecko now is not enough)

>
> There are WebKit patches for Yelp, Devhelp (removes 2000+ lines of Gecko
> embedding code, replaced by ~100 lines of WebKit code and drops the
> requirement for a C++ compiler), some experimental WebKit work in
> Evolution and most (all?) other GNOME applications which use web content.

2000+ lines of code that everyone writes on every app, instead of using
a common API, those 100 lines of code what are doing is hiding the GTK
integration code inside the WebKit GTK port. something similar can be
done maintaining the abstraction layer

>
> As I understand it some of these projects are now just waiting for the
> external dependency to be finalised before switching to WebKit by default.
>
> Speaking as an upstream WebKit maintainer we're happy to adapt the
> project to meet the needs of GNOME developers, both in terms of features
> and in project organisation, release cycle for the GTK+ port etc. We
> want to see software like Epiphany and GNOME become the driving force
> behind browser development rather than the other way round.
>
> I hope this helps clear up some of your concerns.
>
> Cheers!

________________________________________
Robert Marcano

web: http://www.marcanoonline.com/
gpg --keyserver hkp://pgp.mit.edu/ --recv-key 72A0DCFD



_______________________________________________
epiphany-list mailing list
epiphany-list gnome org
http://mail.gnome.org/mailman/listinfo/epiphany-list