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
