On Mon, May 5, 2008 at 1:52 PM, Louis Ryan <[EMAIL PROTECTED]> 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. > > -Louis > > > On Fri, May 2, 2008 at 2:25 PM, Brian Eaton <[EMAIL PROTECTED]> wrote: > > > > > 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 > > -~----------~----~----~----~------~----~------~--~--- > > > > >
