Use Apache shindig to add community content to client applications

Community networks are one of the hottest things on the web today, so it's not surprising that many Web applications are trying to add community Web content to attract more visitors. Although APIs are being standardized, most existing community sites still provide proprietary APIs or support different versions of OpenSocial, which are the challenges many developers face. The result is that OpenSocial now has multiple versions of APIs and lots of open source code to support them. In this article I will discuss how Apache Shindig implements OpenSocial and how to reduce some of these problems.

I'll start with the OpenSocial Standard and shingig architecture, and then explain how they add Community network content to an application. Finally, take the OpenSocial gypsii Community Network as an example to explain the method of enabling shindig.

OpenSocial APIs

Specification defined by OpenSocial:

"OpenSocial is a set of APIs for building social applications that run on the network." The goal of OpenSocial is to make more applications accessible to more users by providing a common API that can be used in many different environments. Developers can use standard JavaScript and HTML to create applications that run on social networking sites that have been applied opensocial. These sites serve as opensocial containers that allow developers to access their community information and, conversely, receive a large number of applications for their users.

The Opensocail API exposes how users and their friend information are captured in a [Community network] container. ”

Community applications are spread around people, activities, and relationships. People are the basic component of Community network software and OpenSocial APIs. The person object provides an interface to the user's information, including basic information about the user or other extended information, such as "Favorite TV show," "I want to Work" and "Favorite Place". The OpenSocial API provides support for viewing and changing personal data. Another important user information is their connection to the social graph. In order to be able to share information and experience the dynamic change of friends, OpenSocial supports the user's concept of friends and provides an API for retrieving information about user friends. When an application wants to interact or display "friend Friend" data, OpenSocial allows you to add an optional filter to your actions to support extended queries, such as users can sort by their friends ' distances. Containers can selectively support "friend's friends" inquiries, "Friends of Friend" queries, and so on. OpenSocial also allows friends to share the information they have been doing recently-these are called activities. The OpenSocial public activity flow is a collection of actions taken by a user. Activity templates allow application developers to define placeholders for applications or user data blocks in a message. This separation of the data layer and the display layer allows multiple activities to be merged into an active package: An activity package that lets users know their friends ' messages without having to work hard to gather a lot of information. Another important aspect of community interaction is the ability to read, post and delete messages between users in the network. OpenSocial defines message types, including public messages (such as file comments) and private messages (for certain individuals and groups only). Message induction, which includes a unique ID, name and amount of information size.

The current specification defines two versions of Api──javascript and rest.

OpenSocial's JavaScript specification is to provide a gadget gadget design to support opensocial functionality. The architecture is shown in Figure 1:

Figure 1 using JavaScript OpenSocial API typical architecture

In this case, a user application is used as a gadgets collection, and gadget uses the Opensoical API to get social information. Therefore, the combination of the JavaScript API and the gadget API is not always suitable for implementations that are not based on gadget.

Conversely, the Opensocail REST API is not directly associated with gadgets, allowing any client application to view and publish the user's opensocial data. We will use these APIs to implement OpenSocial applications.