关于OpenSocial讨论的总结
程序员文章站
2022-07-14 10:13:36
...
最近我写了两篇关于Google OpenSocial的文章，分别是：为什么说OpenSocial只不过是一个公关骗局？和我为什么鼓吹facebook，为什么唱衰OpenSocial？，出乎我自己的意料，这两篇文章得到了异乎寻常的关注，有赞成我的观点，也有反对我的观点，当然也有谩骂的。其中非常感谢那些对OpenSocial很了解的人热情的回复我的文章，指出我文章的错误之处。我今天看了一遍OpenSocial v0.8的文档，想就前面的文章和讨论做一个简单的总结：
Google OpenSocial v0.8增加了REST API，支持服务器端的扩展
之前我看OpenSocial的项目文档，是直接访问到了OpenSocial的中文官方网站(也许是因为我的Google账号设置为默认中文版的缘故)，中文网站至今没有发布v0.8版本，因此我没有注意到REST的支持。今天仔细看了一遍OpenSocial英文官方网站，v0.8版本正式提供了REST支持。准确的来说就是：OpenSocial v0.8支持两种方式的访问：
1、使用gadget访问OpenSocial，本质上是在浏览器端运行的JavaScript，这就是我在前面文章当中一直大力批评的方式。gadget如何发布，官方文档没有明确说明，只是说容器应该提供功能让开发者可以发布，gadget应该运行在containing page里面。
2、v0.8正式公布的REST方式访问OpenSocial，这也是f8平台早就支持的方式,你可以在自己的服务器上面编写程序去远程调用OpenSocial的REST API。至于通过这种方式开发的应用，应该如何发布在容器网站上面，官方文档没有任何说明。
我想从技术角度分别谈谈这两种方式：
1、gadget方式调用OpenSocial
gadget方式其实就是一个页面里面嵌入的widget应用，用AJAX开发出来的。这种方式我否定它的重要原因就是这种方式难以开发高交互式的复杂应用，而SNS的应用要火爆要推广出去，必须是那种交互式很强，越多人参与越有意思的应用，比方说看一下facebook上面那些很火爆的app，都是交互式特别强的app。
gadget方式还有另外一个可能的隐忧：大量AJAX的应用可能会拖慢浏览器的速度，特别是一些mashup的应用，如果gadget开发者无节制的使用JS，很可能导致一进入该containing页面，浏览器就假死。
当然gadget还有一个问题就是源代码泄漏问题了，使得拷贝没有任何成本，这一点前面文章提过，他和网站AJAX应用的JS源代码泄漏其严重程度是不一样的。因为网站的核心竞争力往往并不在那点AJAX效果上面，而gadget的主要竞争力就靠这个了。
不过我看很多朋友在回复我的文章当中，反而更加看好这种“轻”应用的方式，比方说：
其实我觉得Netvibes现在混的一点都不好，iGoogle也没有怎么火起来，这种mashup也很难看到什么商业前景，我也不看好“轻”widget应用，当然关于这个问题见人见智。大家可以多多发表见解。
2、远程调用OpenSocial的REST API
我个人是非常推崇这种方式的开放平台的，对于开发者来说没有任何限制，可以做任何事情。因此如果OpenSocial的开发商都倾向于采用这种方式，那么我前面文章当中对于OpenSocial的一些论断是错误的，请大家不要被我前面的言论误导。
但是OpenSocial文档没有说明app开发商开发的REST应用究竟应该以何种方式呈现在OpenSocial容器网站上面，而我却认为这是至关重要的地方。比方说facebook网站是把自己定位成为一个纯粹的平台网站的，他开放任何数据给app开发商，他把app作为网站的核心价值展现出来，给app开发商最大的利益。
但是作为一个社区网站来说，如果提供这种REST API，就面临一个两难的抉择：如果把app作为网站的重要功能集成进来的话，那么app开发商事实上就在和网站自身争夺用户，网站为了保护自身的利益，就会限制app访问的数据；如果不作为网站重要功能集成的话，app开发商没有动力给你开发app。关于这一点，我在前面文章提到过：
根据我了解到的一些信息来看，国内目前宣布支持OpenSocial的网站当中确实有这种担忧在内，并且开放的并不彻底。
事实上如果SNS网站虽然提供了完整的REST API支持，但是对于app应用的集成方面做的不够，或者说不热心积极整合的话，那么REST API的意义也就不大了。因为对于app开发商来说，开发app的目的是希望利用你SNS网站的平台给我带来流量和用户，如果你不提供整合手段，或者提供整合手段但是不提供良好的app推广方式的话，那我app开发商想要达到的目的根本就没有达到。
而gadget整合进来和app整合进来是不太一样的两回事：整合gadget无非就是在页面里面嵌入一个iframe，在页面开一个小天窗，增加点页面功能而已，对SNS网站本身不会形成什么冲击，有益无害，但是对开发商没有什么利益；而整合app就不一样了，需要你对自己网站本身做很大的改动，能够适应app顺利的整合进来，成为网站功能的一部分，帮助app开发商达到推广他应用和分享利益的目的。因此指望在网站现有基础上增加点OpenSocial，然后很多app就自己来了，这是不可能出现的。天上没有掉馅饼的好事。
探讨一下OpenSocial的前景
尽管OpenSocial规范支持了REST，我前面文章批评OpenSocial的很多理由可以被推翻了，但是OpenSocial的隐忧还是有很多：
1、OpenSocial的版本不一致的问题，这个问题包含两个意思：
1) OpenSocial规范自身一个版本一个版本的升级，网站不可能整齐划一的都支持到最新版本，有的支持v0.5，有的支持v0.6，有的支持v0.7。让开放者开发的应用失去了处处部署的可能性
2) 即使都支持OpenSocial的同一个版本，不同的容器网站支持的功能也各有多少，处处部署是不可能的
2、即使OpenSocial从代码上可以处处部署，但从用户角度也未必可以处处部署
毕竟不同的SNS网站侧重点是不一样的，你在一个SNS网站上面非常受欢迎的app，原封不动挪到另外一个SNS网站就未必会受到这个网站用户的欢迎。特别是国内的社区网站，都会形成一种内在的、独特的、甚至有些排外的社区文化，不同网站的社区文化是不一样的，同样的app不可能到处都吃香，成功的app必然是为这个社区用户和社区文化定制的app。
3、OpenSocial怎么鼓励app开发商？
这个问题我在前面文章详细谈过了，从OpenSocial整个战略来看，并没有考虑到app开发商的利益，而OpenSocial的不可移植性又大大增加了开发的成本，再上了SNS网站自身对于app开发商的利益争夺还是有戒备心理的，那么怎么来形成一个健康的商业生态链呢？我想这个问题我们得拭目以待了，就我个人来说，并不是那么看好。
Google OpenSocial v0.8增加了REST API，支持服务器端的扩展
之前我看OpenSocial的项目文档，是直接访问到了OpenSocial的中文官方网站(也许是因为我的Google账号设置为默认中文版的缘故)，中文网站至今没有发布v0.8版本，因此我没有注意到REST的支持。今天仔细看了一遍OpenSocial英文官方网站，v0.8版本正式提供了REST支持。准确的来说就是：OpenSocial v0.8支持两种方式的访问：
1、使用gadget访问OpenSocial，本质上是在浏览器端运行的JavaScript，这就是我在前面文章当中一直大力批评的方式。gadget如何发布，官方文档没有明确说明，只是说容器应该提供功能让开发者可以发布，gadget应该运行在containing page里面。
2、v0.8正式公布的REST方式访问OpenSocial，这也是f8平台早就支持的方式,你可以在自己的服务器上面编写程序去远程调用OpenSocial的REST API。至于通过这种方式开发的应用，应该如何发布在容器网站上面，官方文档没有任何说明。
我想从技术角度分别谈谈这两种方式：
1、gadget方式调用OpenSocial
gadget方式其实就是一个页面里面嵌入的widget应用，用AJAX开发出来的。这种方式我否定它的重要原因就是这种方式难以开发高交互式的复杂应用，而SNS的应用要火爆要推广出去，必须是那种交互式很强，越多人参与越有意思的应用，比方说看一下facebook上面那些很火爆的app，都是交互式特别强的app。
gadget方式还有另外一个可能的隐忧：大量AJAX的应用可能会拖慢浏览器的速度，特别是一些mashup的应用，如果gadget开发者无节制的使用JS，很可能导致一进入该containing页面，浏览器就假死。
当然gadget还有一个问题就是源代码泄漏问题了，使得拷贝没有任何成本，这一点前面文章提过，他和网站AJAX应用的JS源代码泄漏其严重程度是不一样的。因为网站的核心竞争力往往并不在那点AJAX效果上面，而gadget的主要竞争力就靠这个了。
不过我看很多朋友在回复我的文章当中，反而更加看好这种“轻”应用的方式，比方说：
ScorpioX 写道
你有空可以研究一下Netvibes的结构，他们刚刚开源了。我个人认为一个显示空间和数据操作功能都有很大限制的Widget适合做一些简单的信息发布，例如RSS或邮件。太复杂的交互，Widget就捉襟见肘了。但这并不妨碍我们可以利用Widget来做一些事情，例如我刚给你的Feed在 Netvibes做了一个Widget，呵呵。http://eco.netvibes.com/widgets/241588/javaeye
Netvibes自己也做Social功能，而且也开发了Facebook的Widget，当然不可能把FB的全部功能搬进来，但进行一些短平快的查询还是很不错的。http://eco.netvibes.com/widgets/206745/facebook
Netvibes为什么要这么搞，当然是通过自己平台的能力把FB边缘化，让Netvibes成为你每日必上的网站。所以，从根本上讲，清楚自己的目的最重要。而手段可以层出不穷。
Netvibes自己也做Social功能，而且也开发了Facebook的Widget，当然不可能把FB的全部功能搬进来，但进行一些短平快的查询还是很不错的。http://eco.netvibes.com/widgets/206745/facebook
Netvibes为什么要这么搞，当然是通过自己平台的能力把FB边缘化，让Netvibes成为你每日必上的网站。所以，从根本上讲，清楚自己的目的最重要。而手段可以层出不穷。
其实我觉得Netvibes现在混的一点都不好，iGoogle也没有怎么火起来，这种mashup也很难看到什么商业前景，我也不看好“轻”widget应用，当然关于这个问题见人见智。大家可以多多发表见解。
2、远程调用OpenSocial的REST API
我个人是非常推崇这种方式的开放平台的，对于开发者来说没有任何限制，可以做任何事情。因此如果OpenSocial的开发商都倾向于采用这种方式，那么我前面文章当中对于OpenSocial的一些论断是错误的，请大家不要被我前面的言论误导。
但是OpenSocial文档没有说明app开发商开发的REST应用究竟应该以何种方式呈现在OpenSocial容器网站上面，而我却认为这是至关重要的地方。比方说facebook网站是把自己定位成为一个纯粹的平台网站的，他开放任何数据给app开发商，他把app作为网站的核心价值展现出来，给app开发商最大的利益。
但是作为一个社区网站来说，如果提供这种REST API，就面临一个两难的抉择：如果把app作为网站的重要功能集成进来的话，那么app开发商事实上就在和网站自身争夺用户，网站为了保护自身的利益，就会限制app访问的数据；如果不作为网站重要功能集成的话，app开发商没有动力给你开发app。关于这一点，我在前面文章提到过：
robbin 写道
而且还有一个特别容易被忽视的关键问题：你的网站究竟是做什么的？你是做平台的？还是做社区的？
facebook网站压根就是一个做平台的网站，他的网站架构全部都是为了app服务的，除了app它啥都没有了，就连facebook自己网站提供的所有功能也全部是以app形式出现的。也正因为如此，facebook做平台才能成功。
因此这些网站断然不会扔掉目前网站积累的所有社区资源，孤注一掷的做平台。也正因为没有这样和facebook一样的决心，网站开发和运营的中心还是必然围绕社区展开，其结果就是开放平台永远不会成为他们网站的核心，永远只是锦上添花的功能。因此也就注定了他们的开放平台不会成功。
facebook网站压根就是一个做平台的网站，他的网站架构全部都是为了app服务的，除了app它啥都没有了，就连facebook自己网站提供的所有功能也全部是以app形式出现的。也正因为如此，facebook做平台才能成功。
因此这些网站断然不会扔掉目前网站积累的所有社区资源，孤注一掷的做平台。也正因为没有这样和facebook一样的决心，网站开发和运营的中心还是必然围绕社区展开，其结果就是开放平台永远不会成为他们网站的核心，永远只是锦上添花的功能。因此也就注定了他们的开放平台不会成功。
根据我了解到的一些信息来看，国内目前宣布支持OpenSocial的网站当中确实有这种担忧在内，并且开放的并不彻底。
事实上如果SNS网站虽然提供了完整的REST API支持，但是对于app应用的集成方面做的不够，或者说不热心积极整合的话，那么REST API的意义也就不大了。因为对于app开发商来说，开发app的目的是希望利用你SNS网站的平台给我带来流量和用户，如果你不提供整合手段，或者提供整合手段但是不提供良好的app推广方式的话，那我app开发商想要达到的目的根本就没有达到。
而gadget整合进来和app整合进来是不太一样的两回事：整合gadget无非就是在页面里面嵌入一个iframe，在页面开一个小天窗，增加点页面功能而已，对SNS网站本身不会形成什么冲击，有益无害，但是对开发商没有什么利益；而整合app就不一样了，需要你对自己网站本身做很大的改动，能够适应app顺利的整合进来，成为网站功能的一部分，帮助app开发商达到推广他应用和分享利益的目的。因此指望在网站现有基础上增加点OpenSocial，然后很多app就自己来了，这是不可能出现的。天上没有掉馅饼的好事。
探讨一下OpenSocial的前景
尽管OpenSocial规范支持了REST，我前面文章批评OpenSocial的很多理由可以被推翻了，但是OpenSocial的隐忧还是有很多：
1、OpenSocial的版本不一致的问题，这个问题包含两个意思：
1) OpenSocial规范自身一个版本一个版本的升级，网站不可能整齐划一的都支持到最新版本，有的支持v0.5，有的支持v0.6，有的支持v0.7。让开放者开发的应用失去了处处部署的可能性
2) 即使都支持OpenSocial的同一个版本，不同的容器网站支持的功能也各有多少，处处部署是不可能的
2、即使OpenSocial从代码上可以处处部署，但从用户角度也未必可以处处部署
毕竟不同的SNS网站侧重点是不一样的，你在一个SNS网站上面非常受欢迎的app，原封不动挪到另外一个SNS网站就未必会受到这个网站用户的欢迎。特别是国内的社区网站，都会形成一种内在的、独特的、甚至有些排外的社区文化，不同网站的社区文化是不一样的，同样的app不可能到处都吃香，成功的app必然是为这个社区用户和社区文化定制的app。
3、OpenSocial怎么鼓励app开发商？
这个问题我在前面文章详细谈过了，从OpenSocial整个战略来看，并没有考虑到app开发商的利益，而OpenSocial的不可移植性又大大增加了开发的成本，再上了SNS网站自身对于app开发商的利益争夺还是有戒备心理的，那么怎么来形成一个健康的商业生态链呢？我想这个问题我们得拭目以待了，就我个人来说，并不是那么看好。
上一篇： 对领域模型实现的总结性观点
下一篇： 运维监控产品