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
> -~----------~----~----~----~------~----~------~--~---
>
>

Reply via email to