Er, remove those extra #'s from the iframe url. I think you get my point :)
On Tue, Feb 26, 2008 at 10:16 AM, Kevin Brown <[EMAIL PROTECTED]> wrote: > 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=<http://example.org/gadget.xml&lang=en&country=US&synd=foo&parent=http://foo.com&v=adbfeab43646abadfeab#up_foo=bar&%23up_bar=baz%23rpctoken=3535354646%23st=><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. -- ~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.
