RMR and browser cache

[Brian Eaton <be...@google.com>]

I've been playing around with /robots.txt, and I think the RMR code
might end up causing more browser traffic than we would like for
gadget to container communication under some circumstances.

Imagine N gadgets on a page, all trying to pass a message to the
parent.  Every gadget will create an iframe to <parent>/robots.txt.
If the headers on robots.txt don't explicitly allow browser caching,
that'll end up creating N server round trips.

Or am I missing something?

Re: RMR and browser cache

[Brian Eaton <be...@google.com>]

Thank you for doing the work. =)

On Mon, May 18, 2009 at 11:04 AM, John Hjelmstad <fa...@google.com> wrote:
> I'll be sure to CC you on the code review/commit that implements this. I'm
> completing some other work on rpc.js first. As always, thanks for the due
> diligence.
> --John
>
> On Mon, May 18, 2009 at 11:00 AM, Brian Eaton <be...@google.com> wrote:
>>
>> On Mon, May 18, 2009 at 10:57 AM, John Hjelmstad <fa...@google.com> wrote:
>> > IFPC requires an IFRAME reload for every message chunk sent, not a
>> > one-time
>> > frame load. robots.txt are typically larger in size than rpc_relay.html,
>> > so
>> > I do (still) plan to make it possible for a container to configure
>> > precisely
>> > which relay is used, with robots.txt simply as a fallback.
>>
>> That sounds right.
>
>

Re: RMR and browser cache

[John Hjelmstad <fa...@google.com>]

I'll be sure to CC you on the code review/commit that implements this. I'm
completing some other work on rpc.js first. As always, thanks for the due
diligence.
--John

On Mon, May 18, 2009 at 11:00 AM, Brian Eaton <be...@google.com> wrote:

> On Mon, May 18, 2009 at 10:57 AM, John Hjelmstad <fa...@google.com> wrote:
> > IFPC requires an IFRAME reload for every message chunk sent, not a
> one-time
> > frame load. robots.txt are typically larger in size than rpc_relay.html,
> so
> > I do (still) plan to make it possible for a container to configure
> precisely
> > which relay is used, with robots.txt simply as a fallback.
>
> That sounds right.
>

Re: RMR and browser cache

[Brian Eaton <be...@google.com>]

On Mon, May 18, 2009 at 10:57 AM, John Hjelmstad <fa...@google.com> wrote:
> IFPC requires an IFRAME reload for every message chunk sent, not a one-time
> frame load. robots.txt are typically larger in size than rpc_relay.html, so
> I do (still) plan to make it possible for a container to configure precisely
> which relay is used, with robots.txt simply as a fallback.

That sounds right.

Re: RMR and browser cache

[John Hjelmstad <fa...@google.com>]

That's a reasonable concern, but IMO one still worth the trade-off compared
with IFPC.
IFPC requires an IFRAME reload for every message chunk sent, not a one-time
frame load. robots.txt are typically larger in size than rpc_relay.html, so
I do (still) plan to make it possible for a container to configure precisely
which relay is used, with robots.txt simply as a fallback.

--John

On Mon, May 18, 2009 at 8:00 AM, Brian Eaton <be...@google.com> wrote:

> I've been playing around with /robots.txt, and I think the RMR code
> might end up causing more browser traffic than we would like for
> gadget to container communication under some circumstances.
>
> Imagine N gadgets on a page, all trying to pass a message to the
> parent.  Every gadget will create an iframe to <parent>/robots.txt.
> If the headers on robots.txt don't explicitly allow browser caching,
> that'll end up creating N server round trips.
>
> Or am I missing something?
>