Lalaji,
#5) The handlers will catch any request to the social APIs, including REST
requests, JavaScript requests (via a gadget), or RPC requests. This separates
the back-end service from the request mechanism used to interact with the
service (REST, JavaScript, RPC). The handler's service path is registered with
the system via the @Service tag at the top of the Handler class (e.g.
@Service(name = "activitystreams",
path="/{userId}+/{groupId}/{appId}/{activityId}+")). The handler is then
registered in social/core/config/SocialApiGuiceModule.java. Last, bind the
service provider interface (e.g. ActivityStreamService) to an implementing
class within social/sample/SampleModule.java.
#6) The JSON database has been in use since before I joined the project. My
educated guess for its use is simplicity. Shindig reads from a simple
JSON-based datastore to illustrate sample usage. The expectation is providers
will re-implement the social services using a bone fide database. It's easy to
interact with this database for development purposes. It's also easy to
distribute and run without dependencies on a third party DB provider that must
be started/stopped, etc.
#7) Since the Activity Streams service is accessible as a REST end point, you
may surface this data in which ever way you find most convenient and
appropriate. You can use a server-side request to the Activity Stream
end-point to populate static/dynamic HTML. You may also hit the end-point
using an XHR request in JavaScript.
The advantage of using an OpenSocial gadget is the OpenSocial APIs. It's very
convenient to say "osapi.activitystreams.get(…)" or
"osapi.activitystreams.create(…)" directly in a gadget, as opposed to manually
handling a REST exchange using server-to-server or XHR. In addition,
OpenSocial gadgets are portable across OpenSocial containers, allowing your
application to be surfaced in a variety of environments (including a fancy
embedded experience).
Hope this helps,
- Eric W.
