Now the OpenSocial spec has provided multiple ways for gadget developer to write gadgets. This short article tries to give a quick overview and performance comparison between each of the method. We divide the comparison into 2 parts: a) rendering performance and b) data requesting performance.
Rendering Performance
Traditional model
This model is introduced in the very early stage of OpenSocial (the internal version v0.6), and it's still being used in various gadgets.
In this model, the container fetches gadget spec which is XML format from application server, renders it into HTML page, and send it back to user's client. When client parsing the HTML, social data requests are triggered automatically and they are sent back to container via JavaScript API calls. Since this gadget is hosted on container's server, gadget is not able to issue direct AJAX requests to their home server due to the same-domain restriction. Therefore, all "cross-domain" application data requests are sent through
...
gadget.io.makeRequest
...
calls and the container acts like a proxy to help fetching the data from remote sites.
It's obvious that the process is not that efficient: 3 requests have been triggered by client, and there're totally 5 HTTP round-trips involved for rendering simple 1 gadget. Moreover, its data requesting, which issued through
...
gadget.io.makeRequest
...
calls is not efficient either. We'll discuss it in the a:Data Requesting Performance section.
Proxied Content + Data Pipelining
As one of the major improvements introduced in OpenSocial 0.9, Proxied Content + Data Pipelining is a big step addressing the performance issue in previous OpenSocial versions.
According to the figure, as container fetched the gadget spec and identified the gadget content view to be rendered and displayed is Proxied Content, it sends back the gadget content request to application server with the social data which developer claimed in the gadget spec. In most of the cases, this request is signed with the method roughly the same as
...
gadget.io.makeRequest
...
, indicated by the attribute
...
authz
...
. The key magic here are the direction of social data transmission and the place where rendering happens.
...
- Rather than fetching the social data*after* displaying rendered gadget on the client's screen, which traditional model does, container pushes the required social data to application server before the rendering stage. Therefore the un-necessary social data requesting/responding round-trip is eliminated.
- The gadget rendering process happens on the application side, rather than on the container. This change, comparing to the traditional one, offers extra flexibility to the developer to represent maybe totally different content to specific user. Moreover, since the required social data has been pushed in the step 4, the application data associated with the specific user could be identified in the rendering stage thus no need to be transfered in some separated round-trips.
Yet another big advantage of this approach is the utilizing of Data Pipeline. It's not simply a content caching model but a revolutionary programming pattern. We'll discuss it in the a:following section.
Template + OpenSocial Markup Language + AppData Pushing
Like Proxied Content, Template + OpenSocial Markup Language is also introduced in OpenSocial 0.9. There's continues demanding for a templating language by the developer community to simplify the gadget implementation. As a side effect (maybe), this new comer also improves the rendering performance a lot:
...
Given the gadget spec, which contains pre-defined template, could be cached on the container side, the whole rendering could even be processed with zero application server hit! It's so efficient that it's some containers' only supported rendering model on the user's profile page.
Delegated Content (iframe model in extension proposal)
The Delegated Content model is our new proposed one for extension and hopes it could be adopted in the next version of OpenSocial standard. The main point differentiate it with previous methods is, the gadget content page is hosted on the application server, rather than on container. In other words, the source of this iframed page points to application server. This same-domain behavior brings many benefits including:
...
More information please refer to Remote _ Data _ Requests _ (v0.9)).
Traditional gadget.io.makeRequest (OpenSocial spec version 0.7, 0.8) / osapi.http (0.9+)
...