Details
-
New Feature
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
Description
Copying/pasting email that I sent to shindig-dev@ 1 week ago –
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.