Please ignore :) I responded to the wrong thread.
From: Dan Dumont/Westford/IBM@Lotus To: dev@shindig.apache.org, Date: 12/16/2011 11:32 AM Subject: RE: CommonContainer token refresh changes ddum...@gmail.com on gtalk From: "Ciancetta, Jesse E." <jc...@mitre.org> To: "dev@shindig.apache.org" <dev@shindig.apache.org>, Date: 12/16/2011 09:57 AM Subject: RE: CommonContainer token refresh changes >-----Original Message----- >From: Ciancetta, Jesse E. [mailto:jc...@mitre.org] >Sent: Wednesday, December 14, 2011 1:56 PM >To: dev@shindig.apache.org >Subject: RE: CommonContainer token refresh changes <snip> >Here is a quick and simplified rundown of our rendering process: > >-- An HTTP request comes in to render a given page for a given user >-- We fetch their page from the DB and then enumerate all of the gadgets on >the page -- for each gadget we: >++++ Mint a security token >++++ Make a server-side call to shindig to fetch the gadget metadata >-- We then embed all of the tokens/metadata into the HTTP response we >send down to the client >-- On the client side we initialize a common container object >-- Push the pre-generated tokens and pre-fetched metadata into the >container instance >-- Enumerate each gadget and ask common container to render it >-- Since common container already has a gadget token and metadata there is >no need for any XHR calls back to shindig to fetch anything (and therefore no >need for a container token) > >For gadget token refresh the XHR will be made from the container page back >to the container application (which is all same domain XHR) and since the user >is logged into the container application we know who they are and can >generate updated security tokens for them. It would be helpful for me to have a rough understanding of the rendering process others have in place as I work through the changes needed for getting moduleId's properly set in security tokens. Would those using common container mind describing at a high level what their gadget rendering process is (similar to what I've done above for Rave)? Also -- do other implementer's have the notion of a persistent gadget "instance" ID? I'm pretty sure iGoogle does based on what I've seen in firebug but I'm not sure about others... For example - in Rave a gadget "instance" is an instance of a specific gadget for a specific user. To create that instance the user adds a gadget to their page -- and then no matter what the user does with that gadget from that point forward (like moving it to a different spot on the page, moving it to a different page entirely, ...) the ID of that gadget instance remains the same. That gadget instance ID is what we're using for the moduleId property in our security tokens.
