Purpose
As the OpenSocial spec matures and containers begin to
support multiple versions, there needs to be a way for gadgets to
specify multiple source gadget XML files for various situations. This
will be handled by a single manifest file that identifies to the
container which gadget XML file to utilize based on supported
features.
Objective
This proposal should satisfy the need for a manifest while
allowing for backwards compatibility of existing gadgets already
deployed in production.
Use Cases
Use Case 1: Multiple container deployment
Gadget developer wants their gadget available on a number of containers. Container A currently only supports spec level 1.0. Container B currently supports spec level 2.0. Gadget is already deployed to both Container A and Container B. Author updates gadget to add features only available in 2.0 spec. Original (1.0) gadget has gadget-manifest features added in module prefs to point to new manifest file. Container B, being a 2.0 container, recognizes the manifest file and traces back through the manifest to start using the newer 2.0 gadget source automagically. Container A, being a 1.0 container, ignores the optional "gadget-manifest" feature and continues to serve the older version that it supports.
Use Case 2: Gadget source versioning
Gadget developer wants to be able to switch back and forth between a live and development version of their gadget. Instead of registering and managing 2 distinct gadgets with the container, operating under two different OAuth keys (as we currently see), developer specifies the location of the live and development version of their gadget source with the manifest file.
Specifics:
Location of the manifest:
When uploading a gadget, the developer may specify either the URL of a
gadget XML file OR the URL of a gadget manifest file. The manifest
file will point to the actual gadget XML file URL based on version and
features required/supported. For backwards compatibility purposes,
the gadget XML file may also contain a reference back up to its
manifest file URL. In this way containers that do not support the
manifest feature will still function with their existing gadget XML
sources, and newer containers that do support the manifest feature can
take advantage of its ability to specify multiple gadgets for
different scenarios. This will be done via an optional "gadget-
manifest" feature specified in ModulePrefs.
<Module>
<ModulePrefs title="Manifest sample gadget" description="Example
showing usage of manifest">
<Require feature="opensocial-1.0"/>
<Optional feature="gadget-manifest">
<Param name="manifest">http://example.org/samplegadget/
manifest.xml</Param>
</Optional>
</ModulePrefs>
...
<Module>
(manifest file at http://example.org/samplegadget/manifest.xml
<GadgetManifest>
<Gadgets>
<Gadget os-version="1.0" gadget-version="2.1" status="released"
src="http://example.org/samplegadget/gadget.xml" />
<Gadget os-version="1.0" gadget-version="2.2" status="development"
src="http://example.org/samplegadget/gadget-dev.xml" />
<Gadget os-version="0.8" src="http://example.org/samplegadget/
gadget.os08.xml" />
<Gadget os-version="1.1" src="http://example.org/samplegadget/gadget.
11.xml">
<Features>
<feature name="templates" required="true" />
<feature name="html-6" required="false" />
</Features>
</Gadget>
</Gadgets>
</GadgetManifest>
Processing:
If the container supports the gadget-manifest feature, it attempts to
download the manifest file from the referenced location. It then
selects the source most appropriate to its supported opensocial
version and features. This is true if the manifest file is directly
referenced as the source, or if a gadget file is referenced which
contains a gadget-manifest features. Older containers which do not
support the gadget-manifest feature will simply ignore this directive
and utilize the referenced gadget XML file.