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 On Fri, May 2, 2008 at 12:18 AM, Louis Ryan <[EMAIL PROTECTED]> 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? > > > > > > On Thu, May 1, 2008 at 7:56 PM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > > > On Thu, May 1, 2008 at 7:15 PM, Louis Ryan <[EMAIL PROTECTED]> 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)". > > > > > > > > > > > > > > > > > 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 > -~----------~----~----~----~------~----~------~--~--- > >
