Hi Lalaji, I'm the primary implementor of Activity Streams in Apache Shindig. All of your questions are good. I'll do my best to address each one:
1) There is no intentional mapping between Activity Streams and OpenSocial's "Activity" construct. The "Activity" construct largely considered a legacy data model. It is likely to be displaced by Activity Streams in a future release of OpenSocial. With that said, a strong mapping exists between Activities and Activity Streams simply because of their nature; they both represent some sort of "activity". If you're deciding between using Activities or Activity Streams, I encourage you to Activity Streams only. 2) When OpenSocial adopted Activity Streams, it wrapped Activity Streams with the OpenSocial "way of doing things". All activities are accessed through the OpenSocial REST APIs, which mostly revolve around People. Each ActivityEntry belongs to a person. ActivityEntries may be retrieved by person, by a group of people, or by ID (but still belonging to a Person). They may also be stored on a per application basis, hence the 'appId' field. This accounts for the other fields such as userId, groupId, appId, and SecurityToken (for authorizing API calls). Try not to think of the Activity Streams implementation as a plain-vanilla datastore and REST API for Activity Streams - it's an Activity Stream service within the context of OpenSocial. 3) Good observation. Both Activity Streams and OpenSocial have a "Collection" definition with a few fields: http://opensocial-resources.googlecode.com/svn/spec/2.0/Core-Data.xml#Collection. The Activity Streams Collection model does not really compete with OpenSocial's Collection definition. As such, the OpenSocial collection SHOULD append Activity Stream collection fields when an Activity Stream is retrieved. This is documented in the next section of the OpenSocial spec: http://opensocial-resources.googlecode.com/svn/spec/2.0/Core-Data.xml#ActivityStreamsCollection. This is not currently supported in Shindig today (i.e. only OpenSocial Collection fields are returned). It's something I've been meaning to get to, just haven't had a chance. Since you're clearly getting a good handle on the Shindig code, you're more than welcome to jump on this with me! 4) I'm not aware of additional documentation for Activity Streams beyond the Shindig wiki and OpenSocial spec. However, the Activity Streams implementation follows the same design patterns as the other social APIs in Shindig. I'm sure there's better documentation for this Shindig architecture somewhere, but here's a summary: - A social API request comes in via the REST API, JavaScript API, or RPC - The request is wrapped as a SocialRequestItem and handed off to the appropriate handler (e.g. ActivityStreamHandler). The handler has one method for each HTTP operation (e.g. GET, PUT, POST, DELETE). - The handler parses the request, binds to the appropriate data model (e.g. ActivityEntry), and forwards the data to the appropriate method in the Service class (e.g. ActivityStreamService) for persistence/retrieval. - Shindig comes with a sample persistence layer using a simple JSON-based database (JsonDbOpensocialService.java). I hope this helps, - Eric W.
