SNS设计思路

SNS设计思路（初稿）
由于本人项目经验不足，还无法写出像样的设计文档，所以只能写一下开发思路，具体设计还得进一步总结学习才行。

1.学习OpenSocial,了解SNS的本质是什么，分析什么功能才是SNS必须的。

SNS核心就是人与人的社会关系管理。

在这个平台上大家可以做一些事情，而自己的好友就可以收到活动通知。

参考OpenSocial的文档，SNS最基本的功能有：
a.添加和删除好友
b.添加和删除应用程序
c.存储活动(Activity,UCHome上叫Feed，OpenSocial上叫活动)
d.检索自己和好友的活动流
f.存储和检索每个应用程序和每个应用程序每个用户数据(这个功能有部分SNS并没有实现)
所以架设一个基本框架，支持好友管理、应用程序管理、活动通知管理这三个核心功能即成一个SNS网站。

2.学习Shindig（Apache 孵化项目，OpenSocial容器，有PHP和Java两个版本）
Shindig是开源的OpenSocial容器，支持OpenSocial中所用到的JavaScript协议和RESTful 协议，
基于这个项目可以进行OpenSocial的应用程序的测试，也可以做个支持OpenSocial的网站。

在设计阶段可以通过Shindig的设计和调用方式来指导SNS网站的设计。

3.学习Partuza!（Google Code下的一个PHP样板OpenSocial站点）或SocialSite（Java版的开源OpenSocial站点）
PHP的OpenSocial站点，所用的OpenSocial容器是Shindig的PHP版。

是一个相当简单的SNS 站点实例。

这两个实例中都有数据表的sql文件，可以参考进行数据库等方面的设计。

4.前期功能与领域建模（数据库中要用到的字段可以参考OpenSocial中所定义的一些Field）
用户个人信息：用户名、密码、email
好友关系：
应用程序信息：
用户与应用的关系：
应用程序配置信息*：
活动通知：活动类型，活动正文，活动模版，
……
5.初步分析
课程、培训班与SNS集成问题。

首先不改动Shindig是设计的前提
课程与培训班等关系都在第三方服务器上进行维护，课程与培训班可以等同于校内等群的概念。

参考OpenSocial的数据读写方式，可以指定由课程服务器返回REST格式或RPC格式的数据。

方案一：
如要实现某些功能时可以这样做：
1.得到当前用户所学课程：其它应用向课程服务器请求，输入：站点ID，用户ID，输出：课程列表
2.P在操作一门课程，P的好友都可以看到通知：OpenSocial已经默认支持本API
3.P在操作一门课程，班下的人都可以看到通知：K服务器先把操作记在班级名下，
a方案.用户个人主页上内嵌个K服务器页面,每次用户登录是由班服务器临时查出来，或先静态化（对于班下有成百上千人时用这种方案要好一些，
因为并不是每个人都会去登录，第二是很久登录后那些几百条通知没并没有用处，所以K服务器只记录最新20条也已经是很不错了）
b方案.容器服务器定时从K服务器上查数据（按站点、课程、班级查，同时得到活动列表和用户），由容器服务器进行分发到人。

4.B应用要通知所有学了C课程的人：很明显B是基于K服务器开发的应用，所以B应用必定是要了解K存在的，B直接向容器服务器请求获得K地址，再向K请求通知操作即可。

……
课程与人有关的属性有：创建者、学生、授课老师……。

所有的活动通知的目的是人，所以设计课程API时要定义并使用一些与人有关的常量，用于指定是通知给这个课程下的老师还是学生等
方案二：
用户在班级服务器上登记一个班后自动向容器服务器返回这班下有哪些学生。

由容器服务器将这些班下的学生自动交加为好友。

学生可以解除好友关系，几个人做同一种事情时只显示一条通知：如：“A学生、B学生、C
学生通过了英语四级考试”，
减少课程学习中发送通知的频率，如有些“D学生今天学了英语三十分钟”这一类无关紧要的通知最好就不要发送了。

班下人数不要太多，100个已经是极限了，如果学生加入了三个班，系统自动给安排300个好友，然后300个好友一学习，通知也会太多，看不过来的。

修改概念，不用“好友”而是用如twitter中的“follow”或“关注”这个概念，是好友并不会收到通知，设置为“关注”后才会收到对方的通知。

并且可以关注的人设置上限，如150人为上限这样，课程学习内容自动通知到关注的好友那。

第三方应用要得到课程信息可以类同于方案一。

livemocha分析：
livemocha是一个语言学习的社交网站，也有课程的概念，由于课程永远与学生人数不在同一个数量级，所以livemocha不用实现，也必须不能实现课程内学员活动通知。

如果一门课下有一万人，每天有1%的人学习，则每人每天至少收到100条通知，一共会有100万条通知，这还只是1%的人在学习，再高级的系统也无法实现雪崩式的通知消息，
就算服务器能处理完，人也看不完这些通知。

再者，我根本就不关心的人消息也过来，关心的人消息早就被淹没了。

livemocha不支持第三方应用，事实上也没必要支持，学习社区就是用来学习的，而大部分应用都是游戏的，与社区主旨不合。

因为不支持第三方应用，而且通知是针对人的，不是针对课程的，所以明确的说课程学习与外界的的很多第三方应用是没有多大区别的。

6.初步框架设计
首先完成一个基本框架，此框架实现了好友管理、应用管理、活动通知等基本功能。

然后基于OpenSocial完成基本的如站内信的模块，参考这个示例，其它开发人员可以进行其它模块开发。

第二，设计课程关系管理的框架（可以与SNS容器不在同一个服务器），定义一些课程API，供其它应用使用。

完成一个基于课程框架的示例。

……
由于对课程这一类的业务不了解，目前还不知道哪些是核心功能要做在课程班级框架中的。

参考：
SocialSite
https:///
OpenSocial API 规范
/intl/zh-CN/apis/opensocial/docs/0.8/spec.html
附录：
OpenSocial术语（Jargon）
Ower：所有者，安装了当前应用的用户。

The user who has installed the app
Viewer：查看者，使用当前应用的用户。

The user who is using the app
Friends：好友，两用户的关系。

Relationship between two users
OpenSocial App：OpenSocial应用。

A Gadget Specification compliant
App Data：Data stored by an app
Activity：Data stored by a user (what a user does)
Container：A website
JavaScript API
JavaScript API 位于 opensocial.* 名称空间下，并可提供对三个主要功能区的访问：
用户 -- 有关用户以及用户与用户之间关系的信息
活动 - 可以发布和查看有关用户正在进行的操作的更新
持久化存储 - 在无服务器的情况下，为包含状态的应用程序提供简单“关键值-数据”对的数据存储方案
以下是您可以使用 JavaScript API 执行的操作：
构建应用程序，而无需维护您自己的服务器
构建包含服务器端组件的应用程序（用于从其他网站进行离线处理和/或访问）
创建全新的应用程序
在现有社交网站环境中展示现有的网络应用程序
向现有小工具中添加社交功能
编写可在多个不同社交网站环境中运行的应用程序
JavaScript API 的设计是为了能够使用标准网络技术：
它在 opensocial.* 名称空间中会打包为一组方法。

它可以让您使用任何标准 JavaScript 编程技术和第三方库。

它含有一个完全异步的回调系统以支持丰富的 AJAX 交互操作。

若要使用 OpenSocial JavaScript API 构建应用程序，请查看《使用入门指南》或学习 OpenSocial 教程。

RESTful 数据 API
RESTful 数据 API 将会提供对 JavaScript API 的补充功能，以便您可以通过自己的服务器访问用户、活动或数据。

RESTful 数据 API 的设计同样也是为了使用标准网络技术：
服务器交互是以 RESTful AtomPub 协议为基础的。

验证由 OAuth 进行处理。