关于OpenSocial讨论的总结

最近我写了两篇关于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的主要竞争力就靠这个了。

不过我看很多朋友在回复我的文章当中，反而更加看好这种“轻”应用的方式，比方说：

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现在混的一点都不好，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一样的决心，网站开发和运营的中心 还是必然围绕社区展开，其结果就是开放平台永远不会成为他们网站的核心，永远只是锦上添花的功能。因此也就注定了他们的开放平台不会成功。

根据我了解到的一些信息来看，国内目前宣布支持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开发商的利益争夺还是有戒备心理的，那么怎么来形成一个健康的商业生态链呢？我想这个问题我们得拭 目以待了，就我个人来说，并不是那么看好。