Introduction
The XPToolkit is a collection of loosely related facilities, from which application writers can pick and choose, which provide a platform independent API to some commonly exploited platform-specific machinery, e.g., bringing up a dialog. Not all platform independent facilities fall under the XPToolkit. JavaScript, for example, is a distinct service. Not all the platform specific implementation details can be forced into the XPToolkit. Applications will still contain platform specific code, though they can minimize the amount by exploiting the XPToolkit.
The primary facility we will provide is that of instantiating windows, dialogs, and other hunks of user interface machinery from an XML description. The description will, hopefully, offer equivalent and broader power over the UI than currently supplied by HTML. Allowing UIs to be constructed entirely from XML and JavaScript significantly lowers the bar for UI builders. An application built on this service has the choice to expose it to end-users. This opens up many possibilities including, e.g., 'downloadable chrome', personal customization, etc.
Making UIs as easy to construct as web pages will open up UI evolution to the same massively parallel development that has so richly benefitted open source code.
A client that doesn't overlap the services provided by the toolkit will have a (hopefully, itself portable) kernel of code that does all the non-UI things the app does (like speak http, or implement a database). Along side it, or wrapped around it will be a scriptable interface, e.g., as defined with the XPIDL and XPCOM. The script support provided by this interface will be sufficient to query and set any parameter, or issue any command, that the UI traditionally would have viewed, changed, or issued.
Somewhere accessible, stored in an application specific form, are hunks of UI description--streams of XML--corresponding to hunks of UI machinery. The app might store these descriptions as individual files; as resources; as database entries; or even remotely to be accessed through URLs. Whenever some piece of UI machinery must be instantiated, the app serves up a stream of XML to the toolkits UI poser; and the UI machinery comes into being.
This separation is, of course, older than the hills. It is the Model-View-Controller paradigm touted since Smalltalk days, and in many application frameworks since. Because the app kernel has no knowledge of any particular dialog, window, or menu, it is totally uneffected when the UI designer moves facilities from one dialog to another, or changes their form completely.
This facility alone, helps us build applications faster because our UI builders don't have to wait for our application engineers. We can do even more, however, if we don't `harden' the interface into the built application. The application can expose its interface descriptions to end-users at any level from selecting pre-built alternative `themes', installing entirely new facilities (e.g., from Netcenter), downloadable chrome, locally customizable chrome, right down to giving the user ultimate power over every pixel of the UI. What level to expose is entirely up the application.