Page History

Overview

The common container is a lightweight gadget-and-container framework.

...

• place a localized control of gadget-and-container interaction.
• clearly separates gadget-and-container interaction from container-specific logic.
• allow security, latency, and functionality changes simultaneously in both gadget and container.

Features

Some features are, but not limited to:

• versioned JS loading.
• navigation of gadgets (pop-in and -out on page).
• latency timing broadcasting.
• hooks for gadget+container RPC functionalities.
• pre-loading of gadgets.
• security token refresh.
• user-preference.

APIs

All non-private methods and members can be used publicly.
However, a container client should restrict its usage from the context of the container instance, as much as possible.Specifically, restrict your usage to below --

From shindig.container.Container

// to instantiate a container
var container = new shindig.container.Container(...)

// to instantiate a gadget site
var site = container.newGadgetSite(...)

// to preload / unload (un-preload) gadgets
container.preloadGadget(...)
container.preloadGadgets(...)
container.unloadGadget(...)
container.unloadGadgets(...)

// to navigate / close gadget sites
container.navigateGadget(...)
container.closeGadget(...)

// to get gadget metatadata
container.getGadgetMetadata(...)

// to register gadgets.rpc service in container
container.rpcRegister(...)

// useful constants
shindig.container.ContainerConfig.*
shindig.container.RenderParam.*
shindig.container.ViewParam.*

...

// to manipulate a gadget site
site.setHeight(...)
site.setWidth(...)
// to have container call site via gadgets.rpc.
site.rpcCall(...)

From shindig.container.GadgetHolder

// none

Examples / How to?

Render your first helloworld gadget

...

Security token is an authentication mechanism for gadget rendering, used to get people data, container validation, etc. For security reasons, they have a limited life-time, after which it ceases to work (and your gadget will likely break). CC supports refreshing of tokens by means of requesting for new ones, and pushing them to the gadget who needs, via gadgets.rpc. CC will do in the background (start upon a navigateTo(), preloadGaget(), preloadGadgets(), stop when all gadgets are closed). As a user, you should not need to do anything, but you can see it in action in Firebug. 

What's new?

2010/12/08: Allow gadget render in cajole mode (in dev)

...

Add support for callback upon JS download complete. Specify optional &onload= in /gadgets/js/google.container.js&onload=XXX, where XXX is globally-defined

function window\[XXX\] = function()  

{ ... }

Announcement email

> In Google, we've been developing a lightweight gadget-and-container
> framework, called "common container", to 1) simplify container and gadget
> integration model, and 2) provide near-zero barrier to entry to become a
> gadget container. The framework is a combination of JS (which container
> clients script source) and API RPC endpoints (which provides the JS with
> runtime metadata/information). Many of the features have been implemented,
> and are currently being productionized. Several Google containers are busy
> prototyping (to integrate with common container) with some success and speed.
> Meanwhile, there has been an independent community effort to modernize the
> Shindig container. It has a similar/same set of goals. In the spirit of
> re-use, we would like to bring non-Google-specific work that we've done in
> Google to Shindig. Engineers at Google and Paul Lindner have met, discussed
> and agreed on the motivations and feature sets. Roughly speaking, they are as
> follow –
> 1) JS is served via the gadgets server, as a container feature, ie:
> /gadgets/js/shindig.container?c=1. This will leverage gadget server
> compilation of JS and management of library dependencies through
> transitive-closure.
> 2) Standard JS API to get metadata to render a gadget, ie:
> /api/rpc?method=gadgets.get.
> - API is implemented using an RPC call similar to other APIs (people,
> activities, etc) in Shindig.
> - RPC will return a URL template and gadget metadata, sufficient to generate
> iframe render URL. Also, the response can be cached by the clientto evaluate
> URL template with data for subsequent/similar requests (ie: different user
> preferences) without requiring an HTTP fetch.
> - Also need JS API to refresh a security (/OAuth) token, ie: /api/rpc?
> method=tokens.get. Gadgets requiring tokens, both short- and long-lived,
> relies on the container to have these primed in a timely fashion.
> 3) Standard JS API to render/navigate gadget.
> - Base API renders into an HTML element, ie: container.navigateGadget(string,
> Element)
> - Ideally support double buffering for switching gadgets views, ie:
> gadget.views.requestNavigateTo().
> - Need a standard "ready-to-draw" RPC callback, when the gadget has finished
> initial rendering.
> - Respects preferred width, height and other gadget-specified metadata used
> in rendering.
> - Need rendering "styles" to show gadget in a modal dialog, show hovering
> next to an HTML element, etc.
> - Need concept of a "primary" gadget on the page. Navigating to this gadget
> should fire a callback on the parent page to support navigation in the
> browser bar.
> 4) All RPC APIs (gadgets, people, activities) should be callable form the
> container page.
> - Likely implementation is an iframe on the domain of the gadget host. Web
> site calls gadgets.rpc() to iframe and iframe makes XHR to gadget host.
> - Gadget render iframe URLs can be enhanced for latency-optimizing features,
> ie: container can be an RPC hub for gadgets on the page.
> - RPC responses can be obtained from pre-loaded/cache metadata for latency
> improvements.
> - Need to flesh out a standard API to redirect to a login page from the 3rd
> party site.
> What's next? Discuss. We would very much like to hear your thoughts. In the
> next few days, we will prepare common container code base for public viewing,
> and upon no strong objections, we will send an initial code drop for review,
> where which we can discuss further in greater technical details.