----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/3180/#review4105 -----------------------------------------------------------
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? - Jesse 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 > >
