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.


_______________________________________________
dev-embedding mailing list
dev-embedding@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-embedding

Reply via email to