...
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:
...