How bizarre, I was just having this conversation with a friend yesterday. The token is only read by client javascript, so it can be moved to the url fragment instead of the query string; that was an oversight on my part.
Unfortunately, cachability of iframes is going to be quite low until we have a way to detect user pref hangman variable substitution. When/ if we can make that happen, we could wind up with something like this: /ifr?url= http://example.org/gadget.xml&lang=en&country=US&synd=foo&parent=http://foo.com&v=adbfeab43646abadfeab#up_foo=bar&#up_bar=baz#rpctoken=3535354646#st=<security token> For any gadgets that don't perform hangman substitution of user prefs (no __UP_ variables in the spec xml), we can dramatically improve performance: - Only need to modify the iframe url when the spec content changes, otherwise cache indefinitely - Can cache the gadget in post-localized mode (all __MSG_ and __BIDI_ variables substituted), avoiding repeating this job on every request The module id will still be a bit of a thorn here (and really, it's kind of pointless), but the same basic rule applies as does for __UP. I need to do some more research and get more feedback from gadget authors, but I *think* in the future we can recommend authors avoid __MODULE and __UP hangman variables, and if they do so the performance improvements will be dramatic. There's an open issue on this (shindig 50-something I think), but so far it's been a lower priority than dealing with various open functionality and security issues. If you want to take up the cause, though, by all means go for it. On Tue, Feb 26, 2008 at 7:59 AM, Paul Lindner <[EMAIL PROTECTED]> wrote: > I noticed that we're now passing rpctoken on the args of the iframe > URL. I've been paying particular attention to this because I want the > results of the iframe generation to be cachable. To increase the > cache hit ratio we need to minimize the amount of variance. > > It seems that rpctoken will be custom for each owner/viewer session, > which means that cachability will be quite low. > > Does the presence of this argument affect the gadget server output? > Or can it be passed another way? > > -- > Paul Lindner > hi5 Architect > [EMAIL PROTECTED] > -- ~Kevin If you received this email by mistake, please delete it, cancel your mail account, destroy your hard drive, silence any witnesses, and burn down the building that you're in.
