Incremental preloading of gadget metadata and security tokens

[Ciancetta, Jesse E.]

Hi All,

Common container currently supports a one-time bulk preload of gadget metadata and security tokens via the opt_config parameter passed to the Container constructor, however it would also be useful to have a way to incrementally preload this data as well.

We're currently doing this in Apache Rave by calling the private container.preloadFromConfig_ function for each of our gadgets before calling container.navigateGadget which seems to work just fine, but we obviously don't want to continue to rely on a private function.

Would anyone be opposed to a patch to making the preloadFromConfig_ function public and adding it as part of the formal common container specification?

Thanks,

--Jesse

[Paul Lindner]

This sounds like a good idea.  Michael, John wdyt?

--
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 opensocial-an...@googlegroups.com.
To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.

--
Paul Lindner -- lin...@inuus.com -- linkedin.com/in/plindner

[Ciancetta, Jesse E.]

>The one-time bulk preloaded of gadget metadata and security tokens are for
>server-side inlined data, avoiding XHR.

Right -- and that's exactly what we're looking to do (avoiding those XHR calls) however at the time we construct our common container instance we don't already have all of the metadata/tokens all gathered up to pass to the constructor.

In our use case we have a JavaScript array of mixed "widget" objects on the client side (OpenSocial gadgets, W3C widgets, ...) which we enumerate through at render time, and for any OpenSocial gadgets we end up delegating off to common container for rendering services. We could of course just enumerate that array twice -- once to build up the preload data to pass to the common container constructor and then again to do the actual rendering of gadgets -- but with the ability to incrementally preload metadata/tokens we wouldn't have to.

>We also have incremental (xhr-style)
>gadget preloading -- osapi.container.preloadGadget() -- and it will cache
>metadata on top of what has been preloaded (via both one-time/server-side
>or
>incrementals before hand). Not sure why you'd need to incrementally preload
>tokens, CC keeps track of security-token-requiring gadgets that have been
>navigated (displayed on page) and preloaded (cached, not displayed) and
>update their security tokens accordingly.

[Mark W.]

+1

Andrew, is this something we need to add to the incubating section "2.0 next" spec? If so, I can open that up so we can start working on it.

[rbaxter85]

Jesse, why not just make the call to navigateGadget in the callback to
preload?

[Ciancetta, Jesse E.]

Hi Ryan,

I think we're talking about two different things. I think you're talking about the osapi.container.Container.prototype.preloadGadget(s) functions, and I'm talking about the osapi.container.Container.prototype.preloadFromConfig_ function which (currently) is private and only called once from the osapi.container.Container constructor.

The functions that you're talking about always result in an XHR call back to the server to fetch the metadata (unless it's already in the metadata cache), and also don't do anything to facilitate using pre-generated tokens. The function I'm talking about allows the caller to push pre-generated metadata and tokens directly into the cache (thus avoiding any XHR's when the gadget sites are navigated), however its currently private and only called once from the osapi.container.Container constructor. My problem though is that when I make my call to the osapi.container.Container constructor I don't have all of the metadata/tokens gathered up yet to pass in a single batch, which is why I need to be able to call the preloadFromConfig_ function incrementally.

Please let me know though if I've misunderstood what you meant.

BTW -- I've got a JIRA ticket/patch and review for this issue at the following locations:

https://issues.apache.org/jira/browse/SHINDIG-1579

https://reviews.apache.org/r/1563/

I'd be happy to contribute a spec patch too if this gets accepted and committed to trunk.

Thanks!

--Jesse

>-----Original Message-----
>From: opensocial-an...@googlegroups.com [mailto:opensocial-
>and-gadg...@googlegroups.com] On Behalf Of rbaxter85
>Sent: Tuesday, August 23, 2011 8:45 PM
>To: OpenSocial and Gadgets Specification Discussion
>Subject: [osgs] Re: Incremental preloading of gadget metadata and security
>tokens
>

>--
>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 opensocial-and-gadgets-
>sp...@googlegroups.com.
>To unsubscribe from this group, send email to opensocial-and-gadgets-
>spec+uns...@googlegroups.com.

[rbaxter85]

Thanks for the clarification Jesse. I think we should take this
discussion over to the Shindig dev list since that seems like the
appropriate spot for it. If we decide to make the method public than
we can make the patch to the container spec.