Thanks for getting this process going Michael. This will really make Shindig much easier to use.
Regarding some questions raised below here's my opinions: * Metadata 'render' api should allow an array of [gadget url, moduleId, view] * Metadata api should be flexible enough to form the basis of a gadget directory * I want to see metadata and social calls batchable * Note that with recent checkins we can support fetching JSON-RPC results with JSONP or CORS. * Login popup should be based on OAuth 2.0 User Agent flow, which will allow for easier integration once OAuth 2.0 becomes more widespread. On Wed, May 12, 2010 at 12:31 AM, Michael Hermanto <mherma...@google.com>wrote: > Hi all, > > 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. > > Cheers, > --Michael >
