protobuff 是xml的终结者？

乱码

如果wcf可以用protobuff作protocol，我们就不一定在web layer用xslt来render传回来的数据了，尽管我个人认为linq to xml可能也应该可以胜任高traffic的工作（不确定），进而web layer可以用object来做mvc了。

我个人很不喜欢xlst，可能是没有深入下去。

不知道是否有人在.net的project做过类似的尝试？


pls reference：

http://code.google.com/apis/protocolbuffers/docs/overview.html

http://stackoverflow.com/questio ... buf-in-wcf-services

http://code.google.com/p/protobuf-net/

Bessy

MS是xml的发起人之一。如果MS用google的开源protobuff。就等于MS在windows中用google doc 替代MS office. 开源的产品出问题不能及时的获得支持。

[ 本帖最后由 Bessy 于 2010-8-12 23:11 编辑 ]

dalaohu

protobuff 只是比soap在体积上小一点而已。
但你的client 也要配置这个协议才行。

走内部，你直接endpoint config 成tcpip好了，有啥比的上这个小， 快？
走外部的话soap/xml是业界标准，所有client都能读取，有啥比的上这通用？

你要有空，自己写个以json格式的protocol,我看比他的protobuff小多了。

说实话 google搞的这些东西，别太当回事了。 等他搞成业界标准了再说吧。 什么总结者就差的更远了。

乱码

原帖由 Bessy 于 2010-8-12 23:04 发表
MS是xml的发起人之一。如果MS用google的开源protobuff。就等于MS在windows中用google doc 替代MS office. 开源的产品出问题不能及时的获得支持。

我倒不指望ms支持protobuff，就像ms不再支持xslt2.0和xpath2.0一样，它2007年的时候就打算用linq to xml来代替xlst,不过它在vs 2010增加了对xslt1.0的debug feature,实在令人费解，可能还是不打算放弃这一块吧。

我的想法是争取在我们的产品上用这个，不打算争取到ms的支持。

而且我们现在用的xslt processor也不是ms的产品(ms的processor msxml只支持到xslt1.0,它鼓励用户用system.xml namesapce下的class)，从这个角度来说，ms从这一块跟我们没关系了。

现在各个大的browser都没有对xslt2.0 processor的支持，如果谁想用新标准（其实真不新），只有在server side找third party processor作transform，不过性能还相当不错，就是learning curve和它的前途.....个人不怎么感冒。不过pretty sure很多developer都是xslt的fan，可能以后我也会，但不是现在。

[ 本帖最后由 乱码 于 2010-8-13 11:27 编辑 ]

乱码

原帖由 dalaohu 于 2010-8-12 23:21 发表
protobuff 只是比soap在体积上小一点而已。
但你的client 也要配置这个协议才行。

走内部，你直接endpoint config 成tcpip好了，有啥比的上这个小， 快？
走外部的话soap/xml是业界标准，所有client都能读取，有啥比的上这通用 ...

client side用现有的encode format就可以，不用加自己新的，stackoverflow上有个帖子就说这事的，刚才找了一下没找到，但pretty sure it's there.

刚找到：http://stackoverflow.com/questio ... ol-buffers-and-http

走内部用tcp不错，但protobuff好像内外都支持（不知道它穿firewall能力如何？），我不打算提供给外部的service，如果以后提供，take it off就好。

说起来是否标准，有谁比ie更不标准？人家活得不是好好的，而且有最庞大的用户群，当然我们的产品跟它没法比。

我不是google fan，但它提供一个现成的solution，只要能get around with annoying xslt,我倒很想尝试一下。

[ 本帖最后由 乱码 于 2010-8-13 10:16 编辑 ]

乱码

有人在silverlight上用它。

http://www.codeproject.com/KB/si ... ht-protobufnet.aspx

dalaohu

I never used xslt

Always passing list<t> around

乱码

原帖由 dalaohu 于 2010-8-13 11:27 发表
I never used xslt

Always passing list around

如果application/service layer是build在web service上的而且web layer不是用.net的技术，xlst是很自然的选择之一。

dalaohu

If the service return xdocument or xml as data type
I'll use linq to convert it to domain object

Either way the client never need to deal with xml

Hope this helps?

dalaohu

原帖由 乱码 于 2010-8-13 11:31 发表


如果application/service layer是build在web service上的而且web layer不是用.net的技术，xlst是很自然的选择之一。

Xslt is only for rendering

regardless the language. Is suggest use your data layer deal with wcf service.  Then convert result to your domain object

So your UI tier just display data normally without the painful xslt

乱码

原帖由 dalaohu 于 2010-8-13 11:32 发表
If the service return xdocument or xml as data type
I'll use linq to convert it to domain object

Either way the client never need to deal with xml

Hope this helps?

我起始的想法也是这样，做一个stand alone converter用linq to xml把 convert to object,不过不确定这个solutiion的performance.

我现在想到的solution： web layer hosts mvc中的controller 和view，然后reference application/service layer的 web service,是否转到protobuff倒也不一定了，只要在web layer能拿到object就可以。

我们现在的web layer是classic asp，contiguous integration都没法做，这对team dev真的像噩梦一样。不知道其他script language团队开发的时候automated build tools tool都用什么，或者理论上根本没有。转到mvc，从这方面也可以有很多的benifit.

dalaohu

'view' never is a part of CI

that's why ideally view don't process any logics

however you test view through integration test and integrate that into your CI

乱码

这边提的ci我侧重于automated build,不是test cases. 我们在app/service有test project专门做logic test.

团队script开发，如果有人checkin烂code,尤其是几个人在做同一个section，就很让人头疼。这也是我很不喜欢script其中的一个原因之一，performance/scalability 就是另外一个层面的东西了。

典

我们还在用MSXML+ Javascript， MSXML虽然不支持XPATH2.0，但也不是什么大不了的问题，毕竟MSXML只是用来翻译一下XML, 无非是在某些特定的场合要多写点代码
用新的东西要注意的一个方面是，市场上容易找到这方面的人吗？否则下次换人/加人就有点痛苦。

乱码

原帖由 典 于 2010-8-16 11:20 发表
我们还在用MSXML+ Javascript， MSXML虽然不支持XPATH2.0，但也不是什么大不了的问题，毕竟MSXML只是用来翻译一下XML, 无非是在某些特定的场合要多写点代码
用新的东西要注意的一个方面是，市场上容易找到这方面的人吗？否则下 ...

个人觉得xlst这方面人不那么好找.尽管xlst是functional language,no side-effects,但对functional programming这个方向我更倾向于f#.

protobuff不是什么大东西，training起来就是几个小时的事。

[ 本帖最后由 乱码 于 2010-8-16 17:12 编辑 ]