Agreed, we need to converge in the OpenSocial spec. Obviously, template-internal markup like os:DataSet won't apply more generically, but analogous syntax in <ModulePrefs> could. I'll get a thread started in the OpenSocial spec group. On Thu, Aug 14, 2008 at 10:29 AM, David Byttow <[EMAIL PROTECTED]>wrote:
> 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 > > >
