cachability of iframe URLs

[Paul Lindner <pl...@hi5.com>]

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
plindner@hi5.com

Re: cachability of iframe URLs

[Kevin Brown <et...@google.com>]

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 <et...@google.com> 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 <pl...@hi5.com> 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
> > plindner@hi5.com
> >
>
>
>
> --
> ~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.

Re: cachability of iframe URLs

[Kevin Brown <et...@google.com>]

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 <pl...@hi5.com> 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
> plindner@hi5.com
>



-- 
~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.