Hi Eric, Thanks a lot for your helpful explanation.And yet I'm learning the Opensocail concepts.Hence I hope if I ask more three questions,it will be ok.My questions are inline with your comments.
On Thu, Oct 20, 2011 at 12:45 AM, Eric Woods <woods...@gmail.com> wrote: > 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). > *5)* According to my knowledge,these handlers are required only when we are going to pass social API requests via REST api.Are these handlers useful with javascript API and or with RPC and if yes can you explain it? > - 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). > > *6)* In Shindig code,all the relevant open-social information are stored in json format and json-based database.What's the main purpose to do that? *7)* I tested your implemented sample Activity Streaming gadget in which JavaScript API is used.Isn't it possible to add activity streaming directly into a jsp file instead of a gadget?And I would like to know what's your preferable way. Thanks; > I hope this helps, > - Eric W. -- Lalaji Sureshika Software Engineer WSO2 Inc.
