On Wed, May 12, 2010 at 10:55 AM, Paul Lindner <[email protected]>wrote:
> 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] > Yes, this is what common container is currently doing, and we will maintain this. > * Metadata api should be flexible enough to form the basis of a gadget > directory > Many of the APIs work with JSONs. I think this should be flexible enough for other purposes. > * 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. > All noted. Thanks Paul. > > On Wed, May 12, 2010 at 12:31 AM, Michael Hermanto <[email protected] > >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 > > >
