|
+1 on the proposal. Great work!
Regarding Jeff's proposal, the wording "reship WebKitGTK"
is confusing. We are talking about a pre-req here. All we are going to ship is
Java +JNI code that's supposed to link dynamically to the WebKitGTK sharedlibs
which are expected to be pre-installed. Or did I miss the point
here?
I agree that the answers to a/b/c could better relate to
the requirements a/b/c. Rather than in-lining with the requirements, it could
also work to re-phrase the req at the beginning of the answer, e.g. a) Pre-req:
....
On section [4] suggested workarounds, I'm missing a
statement that we tried to work with the Mozilla Foundation on freezing the APIs
that we need, and what their take was.
Martin
+1
Awesome! Likely the most well researched proposal ever at Eclipse.
A couple small tweaks
- Suggest putting a line at the beginning somewhere saying that "The
Eclipse Project requests approval to reship WebKitGTK under the LGPL because is
addresses critical community needs." Then launch into the whole story.
- "to help in this disregard" --> "to help in this *regard*"
- suggest trimming the answers to a, b, c and putting them with the points.
See below. The idea is to give board members something they can easily parse and
understand (they don't know the ins and outs of this stuff). If they want more
info they can read on.
Anyway, just a suggestion.
Jeff
On 2010-03-16, at 4:45 PM, Mike Wilson wrote:
It's been clear for a while now that using XULRunner as the basis for the
SWT Browser control on Linux has caused significant problems for our
consumers. In current Linux distros, there is a compelling alternative,
WebKitGTK, which is licensed under LGPL. The Eclipse Board has recently
approved a new policy to allow the use of LGPL APIs in certain circumstances.
According to this policy, to approve the request to use the APIs, the board
must determine that:
a) The library or application invoked by the APIs
is a “pre-req,” as defined in the Eclipse Foundation’s Guidelines for the
Review of Third Party Dependencies.
The Browser widget
is an optional piece of the overall platform. WebKitGTK integration is an
enabling adapter that allows the Browser to work on Linux platforms. Without it
the vast majority of Eclipse continues to work.
b) There is no alternative open source software that provides the same or
similar function to the WebKit APIs that can be obtained under a more
permissive license.
WebKitGTK is the only embeddable web browser that provides a frozen API
that is rich enough to meet the Browser's needs and can be counted on to be
pre-installed in modern Linux distributions.
c) The functionality, usability or consumability of the Eclipse project
would be severely restricted or reduced without the
APIs.
Despite being optional, the Browser widget is
widely used in end-user scenarios. Without the use of WebKitGTK the
instability that currently plagues the Browser on Linux will continue and
inevitably reduces the consumability of Eclipse as an application platform for
both product teams and end-users.
In determining these things the board may rely on information provided by
the PMC, and to help in this disregard, the PMC (with the help of our browser
guru, Grant Gayed) investigated and
is pleased to make available the supporting information supplied
below.
<end here with the rest as an appendix.>
determined the following w.r.t. the above points:
a) SWT's Browser
control has remained stable and reliable on Windows and OS X since the Eclipse
3.0 release, and there are many Eclipse-based applications that have a hard
dependency on having a working Browser control at runtime. Eclipse/SWT strives
to provide a cross-platform experience that is as consistent as possible for
its applications, so reliably providing a working Browser control on a
heavily-consumed platform like Linux is essential.
b) The goal of the
Browser control is to embed a natively-available web browser without requiring
the user to specially install it (i.e. it should just be there from the OS
installation). WebKitGTK is the only embeddable web browser that provides a
frozen API that is rich enough to meet the Browser's needs and can be counted
on to be pre-installed in modern Linux distributions.
c) Without the
use of WebKitGTK the instability that currently plagues the Browser on Linux
will continue. Given the breadth of Eclipse applications that depend on having
a working Browser control and that wish to target Linux as a supported
platform, this instability inevitably reduces the consumability of Eclipse as
an application platform.
Every major release of XULRunner on Linux has
caused SWT's Browser control to become less-/non-functional, and we have been
forced to adapt it to the native-level XULRunner changes in our subsequent
Eclipse/SWT releases (see http://www.eclipse.org/swt/faq.php#browserlinux).
This results in Eclipse-based applications not being able to rely on their
Browser controls to work well on Linux distributions with newer native browser
versions than existed when the application's shipped Browser control was
released.
Consequently, Eclipse-based applications deployed to the
field may become broken at a later date, and maintainers of these applications
must constantly monitor when such breakages occur and issue updates based on
corresponding SWT updates. Alternatively, consumers must specify strict
compatibility requirements to ensure such breakages don't occur, which may
force users to move to older browsers, which may not always be possible. As an
example, given that Ubuntu 9.10 ships with XULRunner 1.9.1.3, an application
must be based on Eclipse 3.5.x or newer in order for its Browser control to
work on this Linux distribution.
A sample of the Eclipse/SWT problems
that have been caused by the need to rely on non-frozen interfaces appear
below [1]. Other similar but unrelated problems caused by interface changes
have been fixed without accompanying bug reports [2]. Additionally,
significant native behavioural changes have caused other Browser functions to
become broken [3]. A general question pertaining to these breakages was asked
last year (http://markmail.org/message/uapflk6lgkaicsqz#query:+page:1+mid:vdesauobtmoa2n55+state:results
), but the suggestions that were received in response did not adequately meet
the Browser's needs [4]. Being able to rely on OS-provided frozen native API
is what enables other facets of SWT releases to continue to just work for
years without major change, and with the use of WebKitGTK, the Browser control
should be able to provide a similar level of stability on
Linux.
------------------
[1] Example Eclipse/SWT problems
caused by the need to rely on non-frozen interfaces:
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=213194
: setText crash with xulrunner 1.9 stream (+13 duplicates)
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=214802
: xulrunner 1.9 uses new interface for authentication
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=242644
: eclipse crashes when downloading a file in the internal browser
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=268651
: Make sure Eclipse works with xulrunner 1.9.1beta
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=296284
: xulrunner 1.9.2 changes
[2] Other similar problems:
- Mozilla 1.7:
nsIDOMSerializer
- XULRunner 1.8: nsIFilePicker
- XULRunner 1.8:
nsIHelperAppLauncher
- XULRunner 1.8: nsIProgressDialog
- XULRunner 1.9:
nsICookieService
- XULRunner 1.9.1: nsIScriptSecurityManager
[3]
Changes in native behaviour:
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=214807
: xulrunner 1.9 has changed invalid certificate behaviour
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=259687
: _javascript_ executes asynchronously with xulrunner 1.9
[4] Suggested
workarounds for XULRunner, and why they did not meet our
requirements:
i. Suggestion: Only use frozen interfaces.
- The
Browser cannot do this without providing significantly less functionality than
is needed to fulfill its responsibilities.
ii. Suggestion: Don't use
nsIDocShell anymore.
- This change was made in Eclipse/SWT 3.5. However,
this does not help with the various other unfrozen interfaces currently being
used.
iii. Suggestion: Specify the maxversion more tightly when
auto-detecting a native browser to use.
- This could avoid some crashes,
but would result in no native browser being found for use on newer Linux
distros. Since having a working Browser control on Linux is essential, this is
not an adequate solution.
iv. Suggestion: Ship XULRunner, "treating
Mozilla as a system library is pain and hurt"
- This has been reported to
have limited success since the back-end API needs of XULRunner are diverse,
and unsatisfied shared library dependencies can still occur. A native browser
that is properly integrated with the target OS is needed.
v.Suggestion:
Make XPCOM calls via _javascript_
- This could alleviate some problems
related to member positioning within a class, but would not have helped other
breakages, such as:
- nsIHelperAppLauncherDialog.PromptForSaveToFile() (the
Browser implements this interface):
- grew an argument in Mozilla 1.5
-
changed an argument type in XULRunner 1.8
- grew another argument in
XULRunner 1.9
- nsIDOMSerializer.SerializeToString() changed an argument
type in Mozilla 1.7
- nsIFilePicker.Init() and
nsIFilePicker.SetDefaultString() changed their argument types in XULRunner 1.8
(the Browser implements this interface)
- nsIDownload changed significantly
(>10 method signatures) in XULRunner 1.8 (the Browser implements this
interface)
- the contractID for registering a download factory changed in
XULRunner 1.8
- the XULRunner 1.9 behavioral breakages in
[3]
_______________________________________________
eclipse-pmc
mailing list
eclipse-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-pmc
|
