Mozilla Embedding SDK
by Chak NangaCurrent Problem:
Currently, to embed Gecko into a custom application one has to pull the whole Mozilla tree, build Mozilla, build their custom embedding application, and then extract the embedding-specific components using some manifest files that we provide so that the custom application can be distributed.
Proposed Solution:
Provide an SDK or an "Embedding Toolkit" (ETK) which the user can download and build a custom embedding application with minimal effort - without having to checkout and build the entire Mozilla source tree.
Embedding SDK Goals
The key objective of the embedding SDK is to provide a simple mechanism for users to develop, test and distribute custom applications which embed Gecko. The SDK will provide:
- All the required header files
- Static libraries
- Sample programs on all supported platforms
- Pre-built tools such as xpidl.exe etc. which are useful in building a Mozilla based embedding application.
- Detailed documentation on all key XPCOM and other supported interfaces, tools, core components etc.
- The "Mozilla Runtime Environment" (MRE) [see below]
While there were discussions for having "sub-SDKs" such as XPCOM SDK, Necko SDK etc. this document proposes we forgo that approach for the initial release for the following key reasons:
- Customer demand for "sub-SDKs" : While we could definitely justify a need for an embedding SDK, I'm not really sure if there's such a major push from customers for having, say, a separate Necko SDK. For ex, I would imagine people intending to write a non-Mozilla networking app would be more inclined to write it using the traditional sockets API or something similar rather than using a Necko "sub-SDK".
- Maintenance Costs : Assuming we co-ordinate our embedding SDK releases with major Mozilla releases it would be pretty easy to produce an SDK which has xpcom, necko and all other required support files. However, if we were to go down the path of supporting separate sub-SDKs we risk having to produce and more importantly maintain additional installation programs etc. We also risk the issues of users downloading and mixing different and possibly non-compatible versions of these sub-SDKs. In addition, this isssue will certainly balloon out of control if we ever decide to produce localized versions of these SDKs.
Mozilla Runtime Environment (MRE)
The Mozilla Runtime Environment will be part of the SDK and will be made available as a separate download as well. The Mozilla Runtime Environment will contain support files which are required to run a custom embedding application such as core XPCOM dlls, core embedding components, core networking components etc. The MRE is the runtime portion of the SDK, without the development tools such as xpidl.exe, header files, static libraries etc. The Mozilla Runtime Environment is intended for developers who want to distribute their custom embedding applications with a runtime, and for end-users who have a custom Mozilla based embedding application but need a runtime for it. It is not needed for running the Mozilla embedding SDK itself, but is useful for custom application developers for testing their applications.
Optional SDK extensions:
Optional SDK extensions define packages that extend the core embedding SDK. Supporting additional embedding application functionality via this SDK extensions mechanism will allow us to carve off independent pieces of functionality which are not part of the "core" embedding package. This will address features which a vast majority of embeddors may not need, while a certain smaller percentage of users would be interested in.
We could use this mechanism to support the following functionality:
- Accessibility
- Plugins
- PSM
- Wallet
- Other "non-core" protocol support components
- ???
Proposed SDK Directory Structure:
MOZ_SDK_<Version Number>
│ README
│
├───bin
│ regchrome.exe
│ regExport.exe
│ regxpcom.exe
│ windbgdlg.exe
│ xpidl.exe
│ xpt_dump.exe
│ xpt_link.exe
│
├───include
│ <All required include files go
here>
│
├───lib
│ <All required static libs go
here>
│
├───mre
│ │ README
│ │
│ └───bin
│ ├───chrome
│ ├───components
│ ├───defaults
│ │ ├───pref
│ │ └───profile
│ └───res
└───samples
├───Linux
├───Mac
└───Win32
Initial Platform Support:
- Win32
- Linux
- ???
Major Tasks:
In order to be able to package and ship an SDK and a runtime of the form described above we need to address the following major tasks:
- Frozen Interfaces : We need to get a key set of interfaces to the "FROZEN" state so that custom embedding applications do not break between new revisions of the SDK/MRE. This is a key task we need to get done before we can have a viable and an effective SDK.
- Build System Changes : We need some kind of a mechanism whereby we can build the SDK from the Mozilla tree on an as needed basis. For ex, by running "nmake sdk" or something similar to that nature. We should also be able to generate the Mozilla Runtime Environment(MRE) from a Mozilla tree. We could easily modify our current embedding package config script for this purpose.
- Documentation : We need documentation for the SDK. We should have documentation for all XPCOM interfaces in the SDK, documentation on how to install the SDK/MRE, setup the build environment and to build and distribute a custom application which embeds Gecko.
- Installation scripts: We need xpinstall scripts for installing the embedding SDK and for the Mozilla Runtime Environment.
- QA the SDK: Lastly we need to have extensive QA done on the SDK/MRE on all of the supported platforms.