You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rave.apache.org by "Ciancetta, Jesse E." <jc...@mitre.org> on 2011/08/16 20:45:28 UTC
Incremental preloading of gadget metadata and security tokens
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
Re: Incremental preloading of gadget metadata and security tokens
Posted by rbaxter85 <rb...@gmail.com>.
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.
On Aug 24, 8:44 am, "Ciancetta, Jesse E." <jc...@mitre.org> wrote:
> 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-and-gadgets-spec@googlegroups.com [mailto:opensocial-
> >and-gadgets-spec@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
>
> >Jesse, why not just make the call to navigateGadget in the callback to
> >preload?
>
> >On Aug 23, 7:18 am, "Mark W." <we...@gmail.com> wrote:
> >> +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.
>
> >--
> >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-
> >spec@googlegroups.com.
> >To unsubscribe from this group, send email to opensocial-and-gadgets-
> >spec+unsubscribe@googlegroups.com.
> >For more options, visit this group at
> >http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
Re: RE: [osgs] Incremental preloading of gadget metadata and
security tokens
Posted by "Mark W." <we...@gmail.com>.
+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.
Re: RE: [osgs] Incremental preloading of gadget metadata and
security tokens
Posted by "Mark W." <we...@gmail.com>.
+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.
RE: [osgs] Incremental preloading of gadget metadata and security
tokens
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
>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.
>
>
>On Tue, Aug 16, 2011 at 12:05 PM, Paul Lindner <li...@inuus.com> wrote:
>
>> This sounds like a good idea. Michael, John wdyt?
>>
>> On Tue, Aug 16, 2011 at 11:45 AM, Ciancetta, Jesse E.
><jc...@mitre.org>wrote:
>>
>>> 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
>>>
>>> --
>>> 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-spec@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> opensocial-and-gadgets-spec+unsubscribe@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>>>
>>>
>>
>>
>> --
>> Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
>>
RE: [osgs] Incremental preloading of gadget metadata and security
tokens
Posted by "Ciancetta, Jesse E." <jc...@mitre.org>.
>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.
>
>
>On Tue, Aug 16, 2011 at 12:05 PM, Paul Lindner <li...@inuus.com> wrote:
>
>> This sounds like a good idea. Michael, John wdyt?
>>
>> On Tue, Aug 16, 2011 at 11:45 AM, Ciancetta, Jesse E.
><jc...@mitre.org>wrote:
>>
>>> 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
>>>
>>> --
>>> 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-spec@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> opensocial-and-gadgets-spec+unsubscribe@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>>>
>>>
>>
>>
>> --
>> Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
>>
Re: [osgs] Incremental preloading of gadget metadata and security tokens
Posted by Michael Hermanto <mh...@gmail.com>.
The one-time bulk preloaded of gadget metadata and security tokens are for
server-side inlined data, avoiding XHR. 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.
On Tue, Aug 16, 2011 at 12:05 PM, Paul Lindner <li...@inuus.com> wrote:
> This sounds like a good idea. Michael, John wdyt?
>
> On Tue, Aug 16, 2011 at 11:45 AM, Ciancetta, Jesse E. <jc...@mitre.org>wrote:
>
>> 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
>>
>> --
>> 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-spec@googlegroups.com.
>> To unsubscribe from this group, send email to
>> opensocial-and-gadgets-spec+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>>
>>
>
>
> --
> Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
>
Re: [osgs] Incremental preloading of gadget metadata and security tokens
Posted by Michael Hermanto <mh...@gmail.com>.
The one-time bulk preloaded of gadget metadata and security tokens are for
server-side inlined data, avoiding XHR. 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.
On Tue, Aug 16, 2011 at 12:05 PM, Paul Lindner <li...@inuus.com> wrote:
> This sounds like a good idea. Michael, John wdyt?
>
> On Tue, Aug 16, 2011 at 11:45 AM, Ciancetta, Jesse E. <jc...@mitre.org>wrote:
>
>> 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
>>
>> --
>> 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-spec@googlegroups.com.
>> To unsubscribe from this group, send email to
>> opensocial-and-gadgets-spec+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>>
>>
>
>
> --
> Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
>
Re: [osgs] Incremental preloading of gadget metadata and security tokens
Posted by Paul Lindner <li...@inuus.com>.
This sounds like a good idea. Michael, John wdyt?
On Tue, Aug 16, 2011 at 11:45 AM, Ciancetta, Jesse E. <jc...@mitre.org>wrote:
> 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
>
> --
> 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-spec@googlegroups.com.
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>
>
--
Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner
Re: [osgs] Incremental preloading of gadget metadata and security tokens
Posted by Paul Lindner <li...@inuus.com>.
This sounds like a good idea. Michael, John wdyt?
On Tue, Aug 16, 2011 at 11:45 AM, Ciancetta, Jesse E. <jc...@mitre.org>wrote:
> 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
>
> --
> 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-spec@googlegroups.com.
> To unsubscribe from this group, send email to
> opensocial-and-gadgets-spec+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
>
>
--
Paul Lindner -- lindner@inuus.com -- linkedin.com/in/plindner