Overall, I like this idea, but I have a few comments:
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.
It probably would be, but that's beyond the scope of Shindig :)
>
>
> Javascript API:
>
> /**
> * Gets any data requested with the "OpensocialPreload" feature.
> *
> * @return {opensocial.DataResponse} returns any data requested for
> * preloading
> */
> opensocial.getPreloadData() { ... }
This is just an implementation detail, so it shouldn't be published as a
public opensocial method. I'd suggest attaching it to opensocial in the same
way that we attach the data to gadgets.io for HTTP Preloads.
>
>
> Regards,
> Adam Winer
>
