| Newsgroups |
gmane.comp.mozilla.devel.embedding |
| Organization |
NovaDSP |
| Message-ID |
<[email protected]> |
Some thoughts on this ...
> At least this gives those of us who were hoping for a nice
> embedding story for Gecko a chance for a clean break, so my
> commendations to the Mozilla team for providing clarity on the issue.
'embedding' covers a vast swathe of territory. It is relatively simple
to embed Firefox in an application. It is nigh on impossible to embed
(say) the SVG rendering system in an application, as it has dependencies
on ... almost everything. Firefox was designed to be a standalone
browser and not a collection of components that are easily plugged and
played.
As far as other browsers are concerned (Webkit/Chromium), they too
suffer from gigantism and interdependency. Webkit is extremely difficult
to 'embed' as the trunk relies on proprietary runtimes
(CF/Quartz/Quicktime). There is an OpenCF/Curl/Cairo route but this is
still (I believe) some way off oven-ready.
The Chromium team have done an amazing job in integrating alternatives
in Webkit but at an enormous cost. The current Chromium 'all' 'solution'
(in Visual Studio terms) contains around 500 sub-projects. Little wonder
the only people with the resources to do it are Google.
There is actually a Chrome embedding project but this relies on patching
a good number of sources and cannot be applied cleanly to any arbitrary
release.
Coming back to Firefox and the future, I believe that a good target
would be a Firefox configuration that had no runtime dependencies on
'chrome' and configuration files etc, i.e. reduced to an absolutely
minimal set of dynamically linked libraries. Hook all config/runtime
stuff so the embedding host can supply it in a format and from a
location that makes sense in the deployment environment. Extend and
expose functionality to make it trivial to run headless.
In an ideal world the minimal DLL set could be built and linked as a
static library, which would be useful on smaller machines - think
ucLinux and non-MMU processors. This implies having a build system that
feeds off trunk but provides a greater degree of flexibility. I'd want
to have the option to use static C/C++ runtimes as well.
The acid test for success would be to be able to deploy a single binary
that could display web resources, interactively or otherwise.
Note that the above applies to my current use case, which is embedding
in an existing Windows desktop app where HTML/SVG flexibility and
interactivity are a major boost. However, an embedding project would
probably want to support managed code too, be it C# or Python.
I think we could dispense with activex/flash plugin support.
All of this has to be done in a non-invasive way that takes full
advantage of Mozilla's hard work in testing, and verifying both quality
and adherence to standards.
I think this beyond the resources of a SOC project. Personally, given
the provision of an adequate wage, I'd love to have a crack at this. I'm
open to offers :)
Finally, my thanks too to the Firefox team. Amazing work and a great
product.
ATB
Jerry.