[uniqush] 接口设计
33 views
Skip to first unread message
mon...@gmail.com
Jun 14, 2012, 2:45:49 AM6/14/12
to golang...@googlegroups.com
Hi all,
不好意思，说好分享的，结果没想到工作地点和住的地方太远，吃完饭回家就该洗
洗睡了。加上住的地方前阵子网络条件不太好，就一直拖到现在。
当初这个话题是从给国内微博设计统一接口开始的。个人感觉和uniqush[1]现在的
工作很像，这才想到说分享一下个人的经验。
必须要说，这仅仅是我*目前*的设计方案，并不意味着是最佳的设计方案。
基本说来，整个过程大约可以分成三步：定义概念，定义操作，设计结构。
1. 定义概念
简单说就是整个系统中有哪些参与者。由于是抽象接口，所以这些参与者必须足够
抽象，又能适合特定领域。以uniqush为例（按照我之后的计划，应该叫做
uniqush-push。因为除了uniqush-push以外，未来还会出现其它几个重要组件。不
过为了方便，以下都称为uniqush了），它的功能就是给服务器程序提供服务，让
服务器端程序可以给用户的移动端推送消息。
这就需要定义有哪些参与者。第一个定义的是用户，或者叫订阅者
（subscriber）。它是消息的最终入口。这其实是抽象的一个概念。在google的
c2dm和apple的apns中都没有。对于c2dm，apns，消息的入口是移动终端。而
uniqush中的用户，则对应实际的人。可以想象，一个用户是可以同时拥有多个移
动终端的。这样，一个推送消息发给某个用户，则多个移动终端都会收到这个消息。
第二个定义的就是服务。既然说用户是消息的最终入口，那么，服务就是消息的最
初来源。对于uniqush来说，不同的服务仅仅是用不同的字符串来标识（服务
名）。曾经也考虑过在uniqush中（准确说是uniqush-push中）加入对服务的登陆
认证等功能，但是个人觉得与其提供单一的认证功能，不如建议用户仅仅在内网使
用uniqush，而如果需要认证则可以考虑用一个web服务器在前端做代理，或者让用
户自己定义自己的认证方法。
最后一个概念就是推送服务提供者（Push Service Provider）。因为无论是使用
google的C2DM给android发推送，还是使用apple的APNS给iOS发消息（或者其他的
系统，windows phone，黑莓等等都一样）。所以需要消息发出者（在uniqush中的
服务）提供在各个云上的帐号（C2DM上的，APNS上的等等）。uniqush中的推送服
务器提供者实际也就是用来抽象这些帐号的。
2. 定义操作
定义好概念之后，就需要根据信息的传播途径，定义各个参与者的操作。uniqush
中，消息只有一个方向：从服务到用户，所以操作也很好定义。所有的操作由消息
的来源处发起的。
先是需要让uniqush知道参与者的具体信息。由此就定义了加入/删除推送服务提供
者帐号，订阅/取消订阅，推送这几个操作。
一个原则是：*统一操作语义，定义不同参数*
详细到uniqush，所谓统一操作语义，就是无论对于哪个推送服务提供者
（C2DM，APNS等等），同一个操作都完成同一项任务。比如推送，那肯定就是需要
把消息推送到用户那里。
定义不同参数，意味着对于不同推送服务提供者，可以区分对待。有些参数是每个
提供者都会用到的，可能只是名字不同，需要的只是统一成一个抽象的名字。比如
每个服务都应该会提供一个message的参数，用来告诉uniqush推送什么消息。而有
些参数可能只是某个平台支持（比如APNS的badge参数），那么可以作为推送操作
的可选参数，并且在文档中说明只有某个平台支持。
这么说可能还是比较抽象。一个类比是：一个中国人和一个印度人去餐馆吃饭，餐
馆都会提供点菜的服务，而具体是要中餐还是印度菜，则需要用户自己指定。这个
时候，点菜就是一个操作，而点什么菜则作为参数。
3. 设计结构
时间比较晚了，我就长话短说。uniqush的代码结构分别经历过两次的调整。第一
次把针对推送服务提供者的代码单独分离出来，利用了一套工厂模式，解决不同提
供者对不同服务接受不同参数的问题。第二次是把所有代码分开到不同package
中。现在在github[2]的master那个branch中，就是最新的代码（还没merge到go1
这个branch）。有兴趣的朋友可以读读。
说了半天，个人觉得好像都是很简单的东西。希望能有帮助。说说个人对统一微博
这事的建议：
- 抽象概念：我觉得微博里的参与者很好定义，应该就只有用户，列表（群组），
标签等等。应该各个微博上都差不多。不用怎么太抽象
- 定义操作：好像应该有转发，评论等操作。需要权衡的一点是：可能有些微博没
有评论功能（我知道twitter是没有）。要么干脆不支持评论，要么就是在不支持
评论的微博上自己设计一种评论格式。比如：评论 RT @monnand: 原文
不知道说这么多有没有用。欢迎大家一起讨论。
-Monnand
-------
1. uniqush.org
2. github.com/monnand/uniqush
不好意思，说好分享的，结果没想到工作地点和住的地方太远，吃完饭回家就该洗
洗睡了。加上住的地方前阵子网络条件不太好，就一直拖到现在。
当初这个话题是从给国内微博设计统一接口开始的。个人感觉和uniqush[1]现在的
工作很像，这才想到说分享一下个人的经验。
必须要说，这仅仅是我*目前*的设计方案，并不意味着是最佳的设计方案。
基本说来，整个过程大约可以分成三步：定义概念，定义操作，设计结构。
1. 定义概念
简单说就是整个系统中有哪些参与者。由于是抽象接口，所以这些参与者必须足够
抽象，又能适合特定领域。以uniqush为例（按照我之后的计划，应该叫做
uniqush-push。因为除了uniqush-push以外，未来还会出现其它几个重要组件。不
过为了方便，以下都称为uniqush了），它的功能就是给服务器程序提供服务，让
服务器端程序可以给用户的移动端推送消息。
这就需要定义有哪些参与者。第一个定义的是用户，或者叫订阅者
（subscriber）。它是消息的最终入口。这其实是抽象的一个概念。在google的
c2dm和apple的apns中都没有。对于c2dm，apns，消息的入口是移动终端。而
uniqush中的用户，则对应实际的人。可以想象，一个用户是可以同时拥有多个移
动终端的。这样，一个推送消息发给某个用户，则多个移动终端都会收到这个消息。
第二个定义的就是服务。既然说用户是消息的最终入口，那么，服务就是消息的最
初来源。对于uniqush来说，不同的服务仅仅是用不同的字符串来标识（服务
名）。曾经也考虑过在uniqush中（准确说是uniqush-push中）加入对服务的登陆
认证等功能，但是个人觉得与其提供单一的认证功能，不如建议用户仅仅在内网使
用uniqush，而如果需要认证则可以考虑用一个web服务器在前端做代理，或者让用
户自己定义自己的认证方法。
最后一个概念就是推送服务提供者（Push Service Provider）。因为无论是使用
google的C2DM给android发推送，还是使用apple的APNS给iOS发消息（或者其他的
系统，windows phone，黑莓等等都一样）。所以需要消息发出者（在uniqush中的
服务）提供在各个云上的帐号（C2DM上的，APNS上的等等）。uniqush中的推送服
务器提供者实际也就是用来抽象这些帐号的。
2. 定义操作
定义好概念之后，就需要根据信息的传播途径，定义各个参与者的操作。uniqush
中，消息只有一个方向：从服务到用户，所以操作也很好定义。所有的操作由消息
的来源处发起的。
先是需要让uniqush知道参与者的具体信息。由此就定义了加入/删除推送服务提供
者帐号，订阅/取消订阅，推送这几个操作。
一个原则是：*统一操作语义，定义不同参数*
详细到uniqush，所谓统一操作语义，就是无论对于哪个推送服务提供者
（C2DM，APNS等等），同一个操作都完成同一项任务。比如推送，那肯定就是需要
把消息推送到用户那里。
定义不同参数，意味着对于不同推送服务提供者，可以区分对待。有些参数是每个
提供者都会用到的，可能只是名字不同，需要的只是统一成一个抽象的名字。比如
每个服务都应该会提供一个message的参数，用来告诉uniqush推送什么消息。而有
些参数可能只是某个平台支持（比如APNS的badge参数），那么可以作为推送操作
的可选参数，并且在文档中说明只有某个平台支持。
这么说可能还是比较抽象。一个类比是：一个中国人和一个印度人去餐馆吃饭，餐
馆都会提供点菜的服务，而具体是要中餐还是印度菜，则需要用户自己指定。这个
时候，点菜就是一个操作，而点什么菜则作为参数。
3. 设计结构
时间比较晚了，我就长话短说。uniqush的代码结构分别经历过两次的调整。第一
次把针对推送服务提供者的代码单独分离出来，利用了一套工厂模式，解决不同提
供者对不同服务接受不同参数的问题。第二次是把所有代码分开到不同package
中。现在在github[2]的master那个branch中，就是最新的代码（还没merge到go1
这个branch）。有兴趣的朋友可以读读。
说了半天，个人觉得好像都是很简单的东西。希望能有帮助。说说个人对统一微博
这事的建议：
- 抽象概念：我觉得微博里的参与者很好定义，应该就只有用户，列表（群组），
标签等等。应该各个微博上都差不多。不用怎么太抽象
- 定义操作：好像应该有转发，评论等操作。需要权衡的一点是：可能有些微博没
有评论功能（我知道twitter是没有）。要么干脆不支持评论，要么就是在不支持
评论的微博上自己设计一种评论格式。比如：评论 RT @monnand: 原文
不知道说这么多有没有用。欢迎大家一起讨论。
-Monnand
-------
1. uniqush.org
2. github.com/monnand/uniqush
Reply all
Reply to author
Forward
0 new messages