On Thu, May 1, 2008 at 9:18 PM, 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? 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. > > > > 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 > -~----------~----~----~----~------~----~------~--~--- > >
