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 On Thu, Apr 24, 2008 at 8:44 AM, Cassie <[EMAIL PROTECTED]> wrote: > +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 > > > > > On Mon, Apr 21, 2008 at 11:46 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > > On Mon, Apr 21, 2008 at 10:07 AM, Brian Eaton <[EMAIL PROTECTED]> 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. > > > > > > > > > > Doing preloads only for GET requests sounds reasonable. > > > > > > On Mon, Apr 21, 2008 at 9:58 AM, Louis Ryan <[EMAIL PROTECTED]> wrote: > > > > For the moment just authz, if people have strong feelings about > > > method, > > > > post-body etc Im fine to adjust. > > > > > > > > > > > > > > > > On Mon, Apr 21, 2008 at 7:41 AM, Brian Eaton <[EMAIL PROTECTED]> > > > wrote: > > > > > > > > > > > > > > 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? > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Apr 21, 2008 at 4:33 AM, Cassie <[EMAIL PROTECTED]> wrote: > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Apr 15, 2008 at 12:56 PM, Kevin Brown <[EMAIL PROTECTED]> > > > wrote: > > > > > > > > > > > > > > On Tue, Apr 15, 2008 at 2:45 AM, Reinoud Elhorst < > > > [EMAIL PROTECTED]> > > > > 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 < > > > [EMAIL PROTECTED]> > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Apr 14, 2008 at 4:46 PM, Bruno Bowden < > > > [EMAIL PROTECTED]> > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > ~Kevin > > > > > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups > "OpenSocial and Gadgets Specification Discussion" group. > To post to this group, send email to > [EMAIL PROTECTED] > To unsubscribe from this group, send email to > [EMAIL PROTECTED] > For more options, visit this group at > http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en > -~----------~----~----~----~------~----~------~--~--- > >
