>-----Original Message----- >From: Ciancetta, Jesse E. [mailto:[email protected]] >Sent: Wednesday, December 14, 2011 9:09 AM >To: [email protected] >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.
