Feed posts are presented in both persisted and cached positions. The cache holds the everyone and following feeds. Cache feed is app fabric.When I write a new microblog, its going to get written first to the content db, and then the cached feed. Anyone who follows me will see this post instantly because of the cache. Posting to team site is the same. When I reply to someone post, and I as a use see that post I expect to see the reply as well. If im following the person who created the post, I shold see the reply, if im only following the person who wrote the reply I also should see the post. This is achieved by using the reference threads.If bender posts something on his wall it is stored on his feed. When fry comes and reply to that post, that reply is also stored on benders feed. This is how we keep conversation. In the replier feed there is a post that is called a reference thread. A reference thread refers to the original post. This is how people following only the replier will know about his reply. The reference post is just a guid. All the data is in the original post. This is the same for tags and mentions.Notice the gaps for document and tags. They don’t have persisted storage.That causes two things:You cant write to a document or tag feed directly.You cant consume a document or tag feed directly as well.Only if you follow a tag or document you can see its feed.Anything you see in a document feed is replicated to a persisted feed, like a users feed.Tag feed only shows referenece posts. To get a feed of a tag you can use search! (all the data is already indexed) this is how the tag profile page works.Posting on behalf of is not supported at the moment. Posting can only be done as a context of a user. Might be added in the future.
First of all the information is gatherd. In our case the following feed. Every post has its time stamp available so posts can be sorted and know how recently it was updated. The feed is kept in the cache. Now the feed get sorted (by default newer on top). This is were similar data is removed. For example if you follow a person and he updated a tag you also follow, you wont see this update twice. Next is trim. First is pulling reference post data. If we are unable to get the information in time, the post wont show. Showing data quickly is top priority. Next is security trimming. If a user watching my feed cant see a document im following (by url) he wont see this post. Content of micro blog posts is NOT security trimmed. If I put a link in my post its not getting checked against other users.Last step is seeing the post. There is always a root post and the latest 2 replies.
Social thread has a collection of actors so if a user replied twice to a post, his user data (image, name etc) is only saved once.
How to develop social applications for SharePoint 2013
DevelopingSocial Apps withSharePoint 2013 Johnny Tordgeman @ E4D
The user profiles client APIs are read-only, other than setting the user’s image. No extra files are needed to work with the user profile with REST or JSOM, for C# client object model use Microsoft.SharePoint.Client.UserProfiles.dll Remember to set the request header correctly when working with REST: application/json;odata=verbose If working from an App remember to request correct permissions:
User Profile Service Social DB Content DB Profile DB (per- (per- service) service) (site collection(per-user) Content DBs per-user) People User Site and Personal Feed and tag profile Social tags document storage postsfollowing properties following space
Get followers and followed profiles Add an actor (followed entity) Check if an actor is followed Stop following an actor Get following suggestions
RESTFul http://<siteUri>/_api/ Namespace: SP.UserProfiles Social.following/my Class library: SP.UserProfiles.js
Almost anything can be done with the following API on the client side. No extra files are needed to work with the user profile with REST or JSOM, for C# client object model use Microsoft.SharePoint.Client.Social.dll Remember to create a new SocialActorInfo when you wish to follow an actor. If working from an App remember to request correct permissions:
Feeds storage overview Persisted personal site content Site’s feed DB content DB Cached feed Person Site Document Tag
Creating aggregate feeds on- demand Post Reply Reply
Feed data structureSocialThread Actors Attributes ID SocialPost (RootPost and Replies) Attachment Author ID LikerInfo Text
Everything related to feeds can be done on both JSOM and REST APIs. No extra files are needed to work with the user profile with REST or JSOM, for C# client object model use Microsoft.SharePoint.Client.Social.dll Remember to create a new SocialPostCreationData when you wish to create a post. If working from an App remember to request correct permissions:
So, what is Social?(other than sharing photos and wasting company time) Tags and Documents Following @Mentions Sites Share Likes Followers Discussions and badges
Data-driven and platform independentEasy to use REST and CSOM APIs deliver on any device with a networkconnectionSeparate form from functionFocus on consumer applicationsMobile and desktop applications, web portals, providing social informationin other contextsEverything is liveNo gatherers or timer jobs getting between you and the latest information