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

[Louis Ryan]

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

[Bruno Bowden]

There's some redundancy here because both the Preload and the io.makeRequest have to specify a signed fetch. Is there any way to avoid this redundancy? Along those lines, what happens if the Preload is signed but not the makeRequest? An author could easily try to do a preload and yet have it fail for simple reasons.

<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 =  {};   // forgot "SIGNED" param

gadgets.io.makeRequest("http://www.myhost.com/getdata",  callback, params);

Is this makeRequest preloaded or not?

[Kevin Brown]

On Mon, Apr 14, 2008 at 4:46 PM, Bruno Bowden <br...@google.com> wrote:

There's some redundancy here because both the Preload and the io.makeRequest have to specify a signed fetch. Is there any way to avoid this redundancy? Along those lines, what happens if the Preload is signed but not the makeRequest? An author could easily try to do a preload and yet have it fail for simple reasons.

<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 =  {};   // forgot "SIGNED" param

gadgets.io.makeRequest("http://www.myhost.com/getdata",  callback, params);

Is this makeRequest preloaded or not?

<Preload> is already in the spec (and tied to makeRequest) -- the only change Louis is proposing is allowing authentication (something which has been shown to be necessary by most containers). This functionality is purely an optimization.

The need for redundancy is ugly, but I don't see any other way to do it without making backwards compatibility very difficult. Under Louis proposed model, a gadget server that didn't support <Preload> would still work with the gadget, which seems like a pretty big advantage to me, though we would probably want to be explicit and require that the authz used between <Preload> and makeRequest be identical.

--
~Kevin

[Reinoud Elhorst]

+ 1 on the theoretical side, especially since containers don't have to support the preload (and everything will still work, although with some more latency)

On the practical side: I don't think that the st is sent to shindig at the moment, so preloading a signed request may be difficult. We shouldn't confuse spec with practical implementation though.

Something else: Can we assume that all preloaded content at least allow caching during the lifetime of that single gadget instance? It wouldn't make much sense to preload something that has a no-cache directive...

[Kevin Brown]

On Tue, Apr 15, 2008 at 2:45 AM, Reinoud Elhorst <rei...@hyves.nl> wrote:

+ 1 on the theoretical side, especially since containers don't have to support the preload (and everything will still work, although with some more latency)

On the practical side: I don't think that the st is sent to shindig at the moment, so preloading a signed request may be difficult. We shouldn't confuse spec with practical implementation though.

This is an implementation detail that is easily remedied. The security token solution used by shindig is similar, if not identical, to that used by other implementations, but it still remains just an implementation detail.

Something else: Can we assume that all preloaded content at least allow caching during the lifetime of that single gadget instance? It wouldn't make much sense to preload something that has a no-cache directive...

I don't see that as being incompatible. Preloading something that isn't cacheable just means that I have to take care to refetch it every gadget render. Not ideal, certainly, but if the gadget author would be doing a makeRequest anyway, it's a lot better to incur that latency during the preload in most cases than it is to incur it after the gadget has been rendered.

On Tue, Apr 15, 2008 at 2:38 AM, Kevin Brown <et...@google.com> wrote:

On Mon, Apr 14, 2008 at 4:46 PM, Bruno Bowden <br...@google.com> wrote:

There's some redundancy here because both the Preload and the io.makeRequest have to specify a signed fetch. Is there any way to avoid this redundancy? Along those lines, what happens if the Preload is signed but not the makeRequest? An author could easily try to do a preload and yet have it fail for simple reasons.

<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 =  {};   // forgot "SIGNED" param

gadgets.io.makeRequest("http://www.myhost.com/getdata",  callback, params);

Is this makeRequest preloaded or not?

<Preload> is already in the spec (and tied to makeRequest) -- the only change Louis is proposing is allowing authentication (something which has been shown to be necessary by most containers). This functionality is purely an optimization.

The need for redundancy is ugly, but I don't see any other way to do it without making backwards compatibility very difficult. Under Louis proposed model, a gadget server that didn't support <Preload> would still work with the gadget, which seems like a pretty big advantage to me, though we would probably want to be explicit and require that the authz used between <Preload> and makeRequest be identical.

--
~Kevin

--
~Kevin

[Cassie]

So, to be clear, the only spec change here is to add the "authz" attribute to the "Preload" element, which would be interpreted as Louis described above.

Thanks.
- Cassie

[Brian Eaton]

I read the proposal differently. Any parameter that can be passed to
makeRequest (HTTP, method, post body, etc...) should be an optional
attribute for Preload as well. Or is that not what Louis was trying
to say?

[Louis Ryan]

For the moment just authz, if people have strong feelings about method, post-body etc Im fine to adjust.

[Brian Eaton]

So long as we're clear in the spec about what is supposed to happen if
a preload is done for GET http://something, and then the gadget does
POST http://something instead. Those are different requests, a
preload for one should not impact the other.

Doing preloads only for GET requests sounds reasonable.

[Kevin Brown]

On Mon, Apr 21, 2008 at 10:07 AM, Brian Eaton <bea...@google.com> wrote:

So long as we're clear in the spec about what is supposed to happen if
a preload is done for GET http://something, and then the gadget does
POST http://something instead.  Those are different requests, a
preload for one should not impact the other.

Just changing the verb is one thing, but actually attaching a post body here seems really bizarre.

--
~Kevin

[Cassie]

+1

Okay, so Louis, Brian Eaton, Reinoudm and I are +1s and I think Kevin is a +1.
As long as there aren't any objections this will go into 0.8

- Cassie

[Louis Ryan]

I'd like to propose some amendments to this spec, possibly for 0.8 if people are willing but if not at least for experimental inclusion in Shindig in short-order.

1. Add support for a 'view' attribute which identifies when a Preload should be executed based on which content sections are rendered. This is to allow for different preloads on different views. The value of the attribute is a comma-separated list of views. If the attributes is omitted the preload is always executed

2. Add support for a new authentication mode. SIGNED_OWNER_ONLY. In this situation the viewer information is omitted from the signed request. This is useful when the information returned by the backend does not care about the viewer. A concrete example is a profile view which is non-interactive but shows content that is entirely contextual to the owner. Omitting the viewer from requests for this kind of information allows for significantly better caching throughout the stack Containers which do not implement this mode can fallback to SIGNED.

Thoughts?

-Louis

[Kevin Brown]

On Thu, May 1, 2008 at 7:15 PM, Louis Ryan <lr...@google.com> wrote:

I'd like to propose some amendments to this spec, possibly for 0.8 if people are willing but if not at least for experimental inclusion in Shindig in short-order.

1. Add support for a 'view' attribute which identifies when a Preload should be executed based on which content sections are rendered. This is to allow for different preloads on different views. The value of the attribute is a comma-separated list of views. If the attributes is omitted the preload is always executed

2. Add support for a new authentication mode. SIGNED_OWNER_ONLY. In this situation the viewer information is omitted from the signed request. This is useful when the information returned by the backend does not care about the viewer. A concrete example is a profile view which is non-interactive but shows content that is entirely contextual to the owner. Omitting the viewer from requests for this kind of information allows for significantly better caching throughout the stack Containers which do not implement this mode can fallback to SIGNED.

Is a new auth mode really the right thing here? Why not  authz="signed" user="(owner | viewer | both)".

[Louis Ryan]

Perhaps not.

If the container is not exposing viewer information to the gadget under its ACLing rules SIGNED may already not include viewer. It seems SIGNED_OWNER just makes this explicit. Not sure how to interpret SIGNED &user=viewer when viewer isnt accessible?

[Kevin Brown]

On Thu, May 1, 2008 at 9:18 PM, Louis Ryan <lr...@google.com> wrote:

Perhaps not.

If the container is not exposing viewer information to the gadget under its ACLing rules SIGNED may already not include viewer. It seems SIGNED_OWNER just makes this explicit. Not sure how to interpret SIGNED &user=viewer when viewer isnt accessible?

I suppose -- adding a new auth type is probably easier. Is there any significant demand for viewer-only data at this point? I was hoping to avoid SIGNED, SIGNED_OWNER, and SIGNED_VIEWER.

[Brian Eaton]

For the record, I'd rather see additional parameters to SIGNED
requests rather than new signing methods like SIGNED_FOO. I suspect
SIGNED_FOO will be shortly followed by SIGNED_FOO_BAR5_NOTQUUX, etc...
For this specific case, how about

authz=signed&viewer=false

The signed friends use case would later be handled with

authz=signed&owner-friends=alice,bob,claire

etc...

Cheers,
Brian

[Cassie]

btw - this will go on record for 0.9 stuff.
for 0.8 we will add the simple thing described above and Shindig (or other containers) can of course add extensions.

sorry to interrupt, discuss away!
- cassie

[Louis Ryan]

I think we need something that is reasonably concise to use in the Preload XML element and in the JSON bundle for makeRequest

Adding an attribute for possible variant seems verbose but Im willing to go with it experimentally.

<Preload ....    viewer="[true|false]" owner="[true|false]" ..

it is.

I don't think this is the appropriate vehicle to solve the owner-friends signing problem and folks will just have to wait for the RESTful API for that.

-Louis

[Kevin Brown]

On Mon, May 5, 2008 at 1:52 PM, Louis Ryan <lr...@google.com> wrote:

I think we need something that is reasonably concise to use in the Preload
XML element and in the JSON bundle for makeRequest

Adding an attribute for possible variant seems verbose but Im willing to go
with it experimentally.

<Preload ....    viewer="[true|false]" owner="[true|false]" ..

it is.

I don't think this is the appropriate vehicle to solve the owner-friends
signing problem and folks will just have to wait for the RESTful API for
that.

That makes sense to me as well. Trying to pass friends in makeRequest calls is painful.