Create gadget with embedded experience characteristics based on shindig

Open Social2.0 and Embedded experiences characteristics

OpenSocial is a unified standard for defining the application of social networking sites and accessing data from social networking sites: The Unified gadget Application model and the gadget container; the unified OpenSocial API is used to access data from social networking sites. The release of OpenSocial 2.0 brings a number of new features to OpenSocial. For example, it provides support for the activity Streams, simplifies the gadget format, adds additional OAuth2 support, increases opensearch support, and the embedded experience we'll be talking about (Embedded experiences).

In layman's parlance, Embedded experiences is to embed a service into another service. This allows the user to use the functionality and experience provided by another service without leaving the context of the current service. For example, upload a video address on a social networking site. So, the uploaded video will appear in the form of a video player. Users can manipulate the video as they do at the video site without leaving the current site. For example, when a user receives a notification from a picture-sharing site when using a mail client, the embedded experience in this email will allow the user to browse, store, product, delete, and share pictures as they would in a picture site.

There are now a wide range of embedded experience solutions. Some social networking sites and mail clients identify the URLs in the content and then decide how to render the content of the URLs for the purpose of the embedded experience. Twitter, for example, deals with Youtube video. If you upload a text in Twitter that contains a video URL for Youtube, Twitter will automatically recognize that the URL is a video in Youbute and provide a player for the video to meet the needs of the user, but the user still can't get it as in Yo The Utube experience in the video, but only the ability to play the video. Google's Google's contextual gadgets further provides an analysis of the content that exists in any form of email and uses this content for gadget capabilities.

The OpenSocial community is aware of the need to complete the embedded experience through the direct use of gadget, so in OpenSocial 2.0, the Embedded experiences mechanism is provided (as mentioned in the following if Embedded Experi Ences will represent the Embedded experiences mechanism in OpenSocial). OpenSocial provides Embedded experiences with a different approach to the embedded experience solutions mentioned above. It does not rely on content recognizers to identify content that needs to provide an embedded experience, nor does it provide a rendering scheme for embedded content, but rather to deliver those responsibilities to the content provider. All of this will be done through the opensocial gadget, thus greatly simplifying the work of target services (social networking sites, mail clients, etc.). The target service will not need to do some tedious work like installing a content recognizer. This approach is a major improvement on Embedded experiences, and its characteristics determine the following advantages:

Service Integrity: Embedded content will easily get the most complete service from the content provider and will be rendered in the target service in a form that is fully compliant with the content service usage.

Security: Only after the user approve the gadget will be rendered as an embedded service. It also reduces the likelihood of executing a section of untrusted scripts in a target service such as mail. At the same time, OpenSocial 2.0 supports OAuth 2.0, which can be accessed via OAuth to the services on the content host (there is little elaboration on security issues here).

User-focused: The user can choose the Approve gadget, so the content in the target service will only render the content of the user's attention to the embedded experience. Content that is not of interest to the user will only be rendered as simple HTML.

Flexibility: The target service will not be concerned with the update of the embedded experience service, because the service will not be provided by the target service, and the update of the embedded service needs to be implemented only by the corresponding gadget of the Content service update. And the changes can be easily reflected in outdated content (such as previously sent messages). And users can also flexibly choose whether or not to render embedded content in different use environments.

Data model of Embedded experiences

The OpenSocial 2.0 specification defines the data model for Embedded experiences, which includes the following sections:

URL: This property is used to specify how a Web page is rendered as a Embedded experiences.

Gadget: This property is used to specify how a gadget is rendered as a Embedded experiences.

Context: This property is the content of the Embedded experiences.

Previewimage (optional): This property is a preview picture of Embedded experiences.