Fwd: Proposal : Modify gadget spec to allow for authenticated/signed preloads & allow preloads to be defined per Content section.

[Louis Ryan <lr...@google.com>]

FYI.

http://groups.google.com/group/opensocial-and-gadgets-spec/t/8fddcff4534e6e

---------- Forwarded message ----------
From: Louis Ryan <lr...@google.com>
Date: Mon, Apr 14, 2008 at 3:48 PM
Subject: Proposal : Modify gadget spec to allow for authenticated/signed
preloads & allow preloads to be defined per Content section.
To: opensocial-and-gadgets-spec@googlegroups.com


Hi,

This proposal is intended to extend the Preload element in the gadget spec
to allow a gadget developer to specify that a request for preloaded content
should be signed or authenticated. E.g.

<Preload href="http://www.myhost.com/getdata" authz="signed" />

The content of a Preload request is made available to the gadget developer
by making the equivalent gadgets.io.makeRequest call on the browser without
making a remote call. E.g.

var params =  {gadgets.io.RequestParameters.AUTHORIZATION :
gadgets.io.AuthorizationType.SIGNED};
gadgets.io.makeRequest("http://www.myhost.com/getdata",  callback, params);


There should be no difference between the content returned by a
gadgets.io.makeRequest call regardless of the presence or otherwise of a
corresponding Preload directive in the spec.

In addition I propose allowing the Preload directive to be defined within
<Content .../> sections to allow gadgets and containers to optimize the
executed set of pre-loads for a given view.

Containers that execute Preloads may/should cache preloaded content in-line
with standard HTTP cache controlling directives (Expires, Cache-Control,
Pragma) which can be used by gadget developers to shape their traffic.

-Louis Ryan
Orkut Team