> On 2011-12-23 14:36:01, Jesse Ciancetta wrote: > > I'm trying to respond to the questions Dan posted with his last update but > > I dont see a way to comment there -- so I guess I'll just put my comments > > here... Going to copy/paste Dan's questions and respond to them inline > > below. > > > > --------------------------------------- > > > > > Started porting of Jesse's review here: https://reviews.apache.org/r/1632 > > > and ran into some questions. (todo comments in gadget_site.js) > > > > > I'm wondering how a container would choose to persist a gadget, and what > > > that would mean for it's token. > > > Perhaps some other xhr to save the gadget and get a moduleId and then the > > > container would set the moduleId of the site, > > > which could trigger a token refresh (with the new moduleId). > > > > This doesnt seem like a common use case to me, but maybe I'm missing > > something. I would think that if a container was rendering transient > > gadgets they would stay transient and if a container was rendering > > persistent gadgets they would stay persistent. > > > > So for the transient case -- I could envision rendering a gadget on a > > sidebar somewhere that has something to do with the users current context. > > > > And for the persistent case -- I'm thinking igoogle or rave -- the user > > adds a gadget to their page which is persistent from the start. > > > > Do you have another use case in mind where a transient-but-already-rendered > > gadget is made persistent? > > > > > Some other interesting questions I have from reading Jesse's review: > > > How would we tell the server to use a certain moduleId in a metadata > > > request? > > > > I ran into this issue too. It would be easy enough to just change the > > metadata request format to gadgetUrl:moduleId but the problem with that is > > that it you make a metadata request for 5 instances of the same gadget > > (same gadget spec url but different moduleId's) you'd end up with 5 full > > metadata responses -- and the only difference between them all would be the > > security token. So in my patch I'd left the metadata request it as is. Of > > course that means you now have the potential for two XHR's per gadget > > navigate - one to fetch metadata and another to fetch a token. I think the > > only other option would be to change the structure of the metadata. > > > > Or actually -- come to think of it -- cant we send more than one request at > > a time? Couldnt we send a metadata request and token request together? > > Mahybe that would help. > > > > > Should we do that, or should we let any instances of the gadget which are > > > not persisted use a default token with no moduleId in it? > > > Should we fetch specific tokens, post metadata request, for a gadget if > > > we know we are "restoring" a saved instance?
Following up on my earlier comment about batching metadata and token requests together so we only make one XHR -- I dug into and it looks like we can do it. From a freshly loaded common container page running off of shindig trunk this code seems to do it: ----------------- var gadgetUrl = 'http://localhost:8080/samplecontainer/examples/media/Media.xml'; var metadataRequest = osapi.container.util.newMetadataRequest(gadgetUrl); var tokenRequest = osapi.container.util.newTokenRequest(gadgetUrl); var batch = osapi.newBatch(). add('metadata', osapi['gadgets']['metadata'](metadataRequest)). add('token', osapi['gadgets']['token'](tokenRequest)); batch.execute(function(result) { console.dir(result); }); - Jesse ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/3180/#review4105 ----------------------------------------------------------- On 2011-12-22 21:00:32, Dan Dumont wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/3180/ > ----------------------------------------------------------- > > (Updated 2011-12-22 21:00:32) > > > Review request for shindig, Henry Saputra, Ryan Baxter, li xu, Jesse > Ciancetta, and Stanton Sievers. > > > Summary > ------- > > Initial review of 1st change. Allowing common container to manage container > token refreshes. Also, refresh of gadget security tokens will now wait for > valid container security token before trying to refresh. > > > Diffs > ----- > > > http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/commoncontainer/assembler.js > 1222407 > > http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.gadget/gadget_site.js > 1222407 > > http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js > 1222407 > > http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/service.js > 1222407 > > Diff: https://reviews.apache.org/r/3180/diff > > > Testing > ------- > > Tested code in a private container with some examples of setting no refresh > (ttl = 0) and setting an initial token (if it was written by jsp page to > avoid transaction) etc.. > > > Thanks, > > Dan > >
