Page Comparison

...

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 may be handled by a single manifest file that identifies to the
container which gadget XML file to utilize based on supported
featuresfeatures or by allowing gadgets to embed pointers to up-version or down-version implementations of themselves.

Objective

This proposal should satisfy the need for a manifest while
multiple gadget versions being deployed across multiple containers while allowing for backwards compatibility of existing gadgets already
deployed in production.

Use Cases

Note: There is some overlap between the manifest and view-level features proposal. This manifest proposal allows for more dramatic version differences of the same gadget to be deployed in a way that is backwards compatible. View-level features will only be forwards compatible. The two proposals should be able to coexist without causing interference.

Use Case 1: Multiple container deployment

...

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:

The manifest feature may be supported either through embedded manifest information in the gadget or through an external manifest XML file. In both scenarios this will be supported through a new gadget-manifest feature available in the ModulePrefs section.

Embedded Manifest

Manifest information MAY be embedded within a gadget XML file

Code Block

lang	xml
title	Embedded Manifest Example

<Module>
  <ModulePrefs title="Manifest embedded gadget" description="Example showing usage of embedded manifest">
    <Require feature="opensocial-1.0"/>
    <Optional feature="gadget-manifest">
       <Param name="gadget" os-version="1.0" gadget-version="2.1" status="released">http://example.org/samplegadget/gadget.xml</Param>
       <Param name="gadget" os-version="1.0" gadget-version="2.2" status="development">http://example.org/samplegadget/gadget-dev.xml</Param>
       <Param name="gadget" os-version="0.8" >http://example.org/samplegadget/gadget.os08.xml</Param>
    </Optional>
  </ModulePrefs>
  ...
<Module>

In cases where there are relatively few gadget files to link, this may be the most efficient option. The downside of this option is that the cross-pointers must be kept synchronized between all gadget files.

External Manifest

Scenarios where many gadget source files are associated together or a wide variety of versions and containers are supported are better served by having a single external manifest file.

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.