>-----Original Message----- >From: Dan Dumont [mailto:ddum...@us.ibm.com] >Sent: Wednesday, December 14, 2011 6:16 PM >To: dev@shindig.apache.org >Subject: RE: CommonContainer token refresh changes > >I'm not done yet! I do want to change the behavior to check for a valid >gadget token.
Ah -- ok. Well then it might be worth taking a look at the moduleId patch I dusted off last week then since it does do a gadget token check (and on demand update if needed) as part of the rendering process. Currently it just checks for gadget token existence but adding a check for expiration would be easy to do. >But that check should rely on the container changes I've been making as >well. > > > >From: "Ciancetta, Jesse E." <jc...@mitre.org> >To: "dev@shindig.apache.org" <dev@shindig.apache.org>, >Date: 12/14/2011 04:32 PM >Subject: RE: CommonContainer token refresh changes > > > >>-----Original Message----- >>From: Ciancetta, Jesse E. [mailto:jc...@mitre.org] >>Sent: Wednesday, December 14, 2011 9:09 AM >>To: dev@shindig.apache.org >>Subject: RE: CommonContainer token refresh changes > ><snip> > >>>* Introduce a new callback in the render chain of a gadget that will >>>attempt to refresh tokens (if needed!) and delay the rendering of a >gadget >>>until the new token is found. >> >>That sounds familiar -- I think I did that already when I was doing the >moduleId >>work a couple of months ago. >> >>I'll plan to dust off that patch today and get it integrated back into >trunk and >>put it back out on the review board so we can have another look at it. >> >>I think the roadblock with it last time was that we weren't sure that we >>wanted to treat the siteId as the moduleId because you guys had some kind >>of use case where existing gadgetSite's were re-used to render different >>gadgets. Does that sound about right? > >I've got my moduleId patch realigned with trunk and posted back to the >review board. As I said earlier I think the roadblock last time was >around using the siteId as the moduleId -- but I'm wondering if we >shouldn't just try that model for now and then update it later if we find >that they do indeed need to be different. The review can be found here: > >https://reviews.apache.org/r/1632/ > >As an aside -- the reason I'd mentioned the moduleId patch again now and >sort of rushed to get it realigned with trunk was because I was thinking >that Dan's statement above about "Introduce a new callback in the render >chain of a gadget that will ..." meant that he'd be checking for a valid >*gadget* token (and delaying rendering if not present ...) -- and the >moduleId patch I have actually does that already so I wanted to get that >out so we could build on it if that was Dan's intent. > >But now that I've seen Dan's patch I'm thinking he meant that he'll be >checking for a *container* token only... So if that's the case then >there's not as much synergy between the two change sets as I was >originally thinking. > > >
