Hi Adam,
I think that this is probably a good general solution for preloading data,
but you should definitely take a look at the current proposal for
DataPipelining within the OpenSocial Templates domain (
http://wiki.opensocial-templates.org/index.php?title=OpenSocial_Data_Pipelining).
We have been discussing the need for a special <os:DataSet> markup which can
be processed either on the server or the client (to stay inline with the
concept of client/server agnostic processing of templates). This markup has
all kinds of advantages, which are beyond the scope of shindig-dev. In
addition to the spec, you can also read up on the ongoing discussions
regarding OpenSocial Templates and data pipelining on on the
[EMAIL PROTECTED] mailing list.
I'd like to see how we can align these efforts if at all possible.
David
On Thu, Aug 14, 2008 at 8:49 AM, Adam Winer <[EMAIL PROTECTED]> wrote:
> In the Orkut OpenSocial implementation (pre-Shindig), we have an
> existing OpenSocial API prefetcher that has proven extremely useful in
> reducing latency from initial API requests. Our existing Orkut
> implementation:
> - records incoming API requests
> - uses those records to statistically guess what API calls a
> gadget makes when first rendering
> - fetches the data for those API calls, and inserts the data
> into the gadget
> - transparently intercepts items within the first
> newDataRequest() call and uses the preloaded result instead,
> with no HTTP round-trip if all items are present
>
> This technique successfully delivers content to ca. 90% of gadget
> renders, with another 7% or so gadgets that do not make OpenSocial
> data requests at all. Overall, this eliminates more than 2 out of
> every 3 data requests in production.
> I've been thinking over how to bring it into Shindig, and would like
> to start with a declarative approach via an optional feature,
> OpensocialPreload. Statistical sampling would be a follow-on
> implementation detail to provide a similar optimization for those
> not declaratively specifying the feature (though I'm happy to share
> more details on how it could work.)
>
> XML:
> <Optional feature="OpensocialPreload">
> <!-- key "viewer", fetch the viewer data -->
> <Param name="viewer">
> /people/@viewer/@self
> </Param>
> <!-- key "friends", fetch the viewer data -->
> <Param name="friends">
> /people/@viewer/@friends?count=20
> </Param>
> </Optional>
>
> Note: the method is GET. POST/PUT/DELETE cannot be preloaded.
>
> A big problem with this syntax: just as the <Preload> entry supports
> "views" entry, this needs to as well. I don't see an obvious way to
> shoehorn this into the existing Gadget spec. Is there any support for
> per-view features? A "views" attribute on features would be useful
> here.
>
> Javascript API:
>
> /**
> * Gets any data requested with the "OpensocialPreload" feature.
> *
> * @return {opensocial.DataResponse} returns any data requested for
> * preloading
> */
> opensocial.getPreloadData() { ... }
>
> Regards,
> Adam Winer
>
