您所在位置：主题：[原创][转]看到一个讨论对比opensocial和F8的帖子,共享
猫猫果儿
[专家分：0] 发布于 2009-01-05 20:19:00
原帖地址：[url=http://freefispace.blogspot.com/2008/12/opsf8.html]http://freefispace.blogspot.com/2008/12/opsf8.html[/url]
作者：北京理工大学 王硕
Opensocial和F8的博弈
这次Google hackathon的深刻印象,有来自Google名扬天下美食,还有Google 天才工程师和各大SNS平台的大牛们,还有在Shawn Shen的推荐下做了一次GAE的临时工程师.
当然最大的收获在于有一次把Idea变成了现实.EasyWrite 让我从此把庞大复杂的Gmail变成了一个简单的备忘录. 最近在看Turing Award演讲集.其中1974年的唐纳德.克努特的<计算机编程艺术>让我觉得:
最自由的程序员的就是随时把自己的idea变为现实.虽然我一直不把自己定位于一个Programmer.
Opensocial的出现是备受争议的.不管是宏观到产品发展战略,还是围观到它的设计哲学.
但不论怎样,我该关心的,就是它是否适合开发者.在这里,衡量的标准,我坚持Jobs的Easy & Useful.
简单的搜索了一下关于 OPENSOCIAL的开发讨论.不少朋友都认为开发曲线比较陡峭.特别是需要对Javascript的能力.不过,任何一个杰出的行动都要经历3个步骤:贬低,讨论,行动.无论F8,OPS.
不管怎样,自己尝试是最好的. 说说我的理解:
区别1:微观的API调用行为.
OPS(这里我们简称OpenSocial)的是基于Javascript实现API容器.而F8是基于Http请求URL. 起初我觉得单独的一个URL访问是很直接明了的.然后和Google工程师Niucl做了一下讨论.他给了我一个很简单的回答,那就是OPS封装了这些具体的请求过程.从而使用户把注意力完全集中到了API中.而且OPS提供了更为丰富的API内容. 所以问题就在于,Google是假设用户具有一定Javascript开发水平的.
区别2:宏观的设计模式.
F8是放到了服务器.而OPS则是放到了客户端.然后再发回服务器.开始我不理解OPS为什么要多这一条生产环节.目前我觉得合理的理解是1.减轻应用程序服务器负担,2.用户体验更加直接.这样来自API返回数据的处理,是先交给了javascript,当然也可以再通过Ajax发回APP-SERVER,但从效率和性能上来说,这就不言而喻了. APP本身规模和返回数据的复杂性而言,也许并不需要交给BLL层. 不管这是不是处于OPS的本意,我认为这点还是符合我对APP的定位的.因为基于SNS的APP不需要太复杂的逻辑.否则这和用自己服务器搭建一个地道的SAAS有什么区别?
还有一个我很赞同的设计理念是统一了API SDK.OPS是强制于Javascript.JS的解释环境是主流浏览器都具备的. 对于F8标准,不同语言需要不同的SDK. 比如国内某些SNS的F8-xAPI的Python SDK就是我上海的一个朋友Damien从FACEBOOK的SDK改的.而且不仅不同开发语言间切换有难度,在不同SNS的API环境中切换也是一个难度.
而F8的优势,在于直接明了.SDK通过嵌入到BLL使得开发过程更加集中,因而提高了APP代码本身的内聚性,也更传统.OPS虽然通过 JS来试图延缓生产瓶颈,但正如我刚才提到的APP的定位,或许它本身的计算强度对BLL来说轻而易举.
所以总的来说.Google和Facebook的开放平台标准之争已经形成了一个纳什均衡的博弈格局. 竞争才有进步,这是我最希望看到的.
而将来我会采取什么标准来开发,把开发成本+挑战难度+心情结合起来吧.呵呵.
其实我最关心的是Google什么时候能举办一次关于App Engine 的Hackathon. :)
作者：北京理工大学 王硕
Opensocial和F8的博弈
这次Google hackathon的深刻印象,有来自Google名扬天下美食,还有Google 天才工程师和各大SNS平台的大牛们,还有在Shawn Shen的推荐下做了一次GAE的临时工程师.
当然最大的收获在于有一次把Idea变成了现实.EasyWrite 让我从此把庞大复杂的Gmail变成了一个简单的备忘录. 最近在看Turing Award演讲集.其中1974年的唐纳德.克努特的<计算机编程艺术>让我觉得:
最自由的程序员的就是随时把自己的idea变为现实.虽然我一直不把自己定位于一个Programmer.
Opensocial的出现是备受争议的.不管是宏观到产品发展战略,还是围观到它的设计哲学.
但不论怎样,我该关心的,就是它是否适合开发者.在这里,衡量的标准,我坚持Jobs的Easy & Useful.
简单的搜索了一下关于 OPENSOCIAL的开发讨论.不少朋友都认为开发曲线比较陡峭.特别是需要对Javascript的能力.不过,任何一个杰出的行动都要经历3个步骤:贬低,讨论,行动.无论F8,OPS.
不管怎样,自己尝试是最好的. 说说我的理解:
区别1:微观的API调用行为.
OPS(这里我们简称OpenSocial)的是基于Javascript实现API容器.而F8是基于Http请求URL. 起初我觉得单独的一个URL访问是很直接明了的.然后和Google工程师Niucl做了一下讨论.他给了我一个很简单的回答,那就是OPS封装了这些具体的请求过程.从而使用户把注意力完全集中到了API中.而且OPS提供了更为丰富的API内容. 所以问题就在于,Google是假设用户具有一定Javascript开发水平的.
区别2:宏观的设计模式.
F8是放到了服务器.而OPS则是放到了客户端.然后再发回服务器.开始我不理解OPS为什么要多这一条生产环节.目前我觉得合理的理解是1.减轻应用程序服务器负担,2.用户体验更加直接.这样来自API返回数据的处理,是先交给了javascript,当然也可以再通过Ajax发回APP-SERVER,但从效率和性能上来说,这就不言而喻了. APP本身规模和返回数据的复杂性而言,也许并不需要交给BLL层. 不管这是不是处于OPS的本意,我认为这点还是符合我对APP的定位的.因为基于SNS的APP不需要太复杂的逻辑.否则这和用自己服务器搭建一个地道的SAAS有什么区别?
还有一个我很赞同的设计理念是统一了API SDK.OPS是强制于Javascript.JS的解释环境是主流浏览器都具备的. 对于F8标准,不同语言需要不同的SDK. 比如国内某些SNS的F8-xAPI的Python SDK就是我上海的一个朋友Damien从FACEBOOK的SDK改的.而且不仅不同开发语言间切换有难度,在不同SNS的API环境中切换也是一个难度.
而F8的优势,在于直接明了.SDK通过嵌入到BLL使得开发过程更加集中,因而提高了APP代码本身的内聚性,也更传统.OPS虽然通过 JS来试图延缓生产瓶颈,但正如我刚才提到的APP的定位,或许它本身的计算强度对BLL来说轻而易举.
所以总的来说.Google和Facebook的开放平台标准之争已经形成了一个纳什均衡的博弈格局. 竞争才有进步,这是我最希望看到的.
而将来我会采取什么标准来开发,把开发成本+挑战难度+心情结合起来吧.呵呵.
其实我最关心的是Google什么时候能举办一次关于App Engine 的Hackathon. :)
