The WHIP core module provides the underlying functionality for both the native launcher applications and the embedded application code. The main component is the org.whipplugin.Whippet class. This class keeps a map of local applications mapped to particular data types identified by a URI. For example, the Triana workflow enactment engine is mapped to a data type URI (urn:trianacode.org:taskgraph) representing the XML format required by Triana to load and run a workflow. A WHIP bundle should contain the data type in the metadata, allowing the Whippet to work out what local application should handle the bundle.
A Whippet also acts as the sender and receiver of bundles (and anything else for that matter). It uses HTTP to send and receive data. Hence, a Whippet is essentially a small Web server and client.
A WHIP-aware application implements a simple Java interface to be able to receive and send bundles. (See the App module). The diagram below shows the process by which a WHIP-aware application is invoked when a user clicks on a WHIP bundle.
When a user clicks on a bundle, either in a browser or file system interface, the native launcher application for the particular operating system is invoked. This creates a new Whippet which tries to match up the data type in the bundle with a locally installed application. If the application is WHIP-aware, then it will have a small HTTP server running. The Whippet invoked by the native launcher tries to find this Whippet. If it is found, then the bundle is sent to it. On receipt of the bundle, the application component is notified of its arrival. If no running Whippet is found, then the Whippet invoked by the native launcher stores the bundle locally and then starts up the application. At start up, the WHIP code embedded in the application looks for any bundles that might be stored locally. If one is found, it is passed to the application component.
TODO: describe the ways of adding apps to WHIP repository
TODO: examples of Whippet
