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