主题：【原创】我有一个问题 -- 美人他爹
家园 那就一个问题。为什么做HTML传输时，人们没有选择 现成的SMTP，而选择了HTTP？
家园 过于追求“第一推动力”，其实没有太大意义 在当初实现之初，http就是设计为简洁高效的文本传输协议的。所以一开始用这个没什么奇怪的－－当然，反过来说，不用它，其实也没什么奇怪的。
而人们总是有惰性的，只要一套系统还能跑，还有扩充和兼容的余地，人们就会有限选择改进它，而不是重构它，更别说推倒重来。虽然和当初的初衷和设计相比，早已经面目全非，但是作为历史遗留问题，存在就是道理。
家园 那按您的逻辑，stateful 的SMTP。TELNET FTP，都可以满足HTML传输要求对吧。HTML内容本身并不要求stateless传输的。那么说按人都是有惰性的说法，就根本不该出现HTTP协议了，因为这是典型的推倒重来，尤其是HTML over SMTP很快就实现了。至于您说的：虽然和当初的初衷和设计相比，早已经面目全非，但是作为历史遗留问题，存在就是道理。您可能想不到，HTTP协议自HTTP1.1以来已经有近10年没有变动了（RFC 2616，1999年6月通过），倒是您非常推崇的HTML，一直在修修补补。
老是提示2小时内20贴，这是怎么回事呢。晕。
家园 这就是很细节的争论了 当然，我不是那个年代过来的，所以不清楚具体的情况。
但是，一般来说，如果出现这些情况，原因无非是几种情况：要么是原作者的偏好、要么是当时没有其他协议很好的二次开发库、要么是当时的实现在某些方面有问题。
这其实没什么太奇怪的，我也没什么兴趣在这方面过于追究。例如说c当初没有定义bool类型，所以各个C的库，都弄出五花八门的bool，相信熟悉c的人，随手都可以列举一大串。到了现在，C99终于有了bool（还是_bool？），但是那些山寨版的依然大行其道。这个时候，我们来问：为什么c语言有bool，但是依然有那么多库自己非要弄一套？类似的例子还有很多，例如说定长整形也是这样。
btw，我并不推崇html，事实上我干的活，基本上从来没和html怎么打过交道。所以它怎么好也罢，怎么不好也罢，我都没有深入的认识。所以在这方面，我也只是从我的某些其他经验来推断和分析的，一家之言而已。
家园 唉。这个架吵得我实在是没什么意愿再吵下去。 我承认您说的都有道理，而且这种讨论确实会陷入这样的矛盾境地，就是谁都无法实证哪种转换的效率低（比如说主机顺序到ANSI的转换效率高低与be/le转换效率的高低），这样谁都只能选择对自己有利的去讲，比如您就选择说如果大小写相关，可HTTP本身跟大小写没有任何关系嘛，为什么非要挑大小写转换这样的例子来说明呢。您说be/le在电路级转换效率很高，这有点抬杠了，问题就在于这虽然很简单，任何一个学数电的学生都会做，但哪个CPU，哪个主板上专门做了le/be转换的电路啊。
我只是陈述一种客观事实，所有基于BINARY的RPC都完蛋了，从CORBA开始，到RMI结束，我试图说明为什么这么多binaryRPC都不行，所以才列举了这些因素。我觉得讨论一下为什么binary RPC会失败，意义可能更大一些。
家园 如果有必要的话，哪个CPU都会提供 为什么没有没有提供？
那是因为现在主流CPU提供的位运算能力，已经足够强，所以没有这个必要了。如果以后某个主流应用中be/le的转换性能成为瓶颈的话，这个功能绝对会加上去。
不信？瞧瞧现在各大厂商为了优化javascript的性能，花了多少心思吧？只要在商业上有必要，技术上可能，这些优化绝对会做。
所以现在不做，仅仅是因为不需要，或者说目前已经足够强了。
家园 我觉得，您还是继续讨论一下。 何以RPC技术出现这么多年，binary方式的都失败告终？而HTTP RPC大行其道，这是为什么呢。这个问题较有意义一些。我另一个贴子也说了，我本身原来支持的是HTTP的stateless，而非文本化，如果您一定要认为文本不如binary的话，那我觉得讨论stateless更好。
家园 Amazon使用新协议上传大数据块 http://www.ccthere.com/article/2424203
家园 那个是传输层 楼主问的是协议层
传输层更复杂，协议层花头更多
家园 已合并于最新回复，请无视这一篇。 DEL
家园 已合并于最新回复，请无视这一篇。 DEL
家园 已合并于最新回复，请无视这一篇。 DEL
家园 已合并于最新回复，请无视这一篇。 DEL
家园 已合并于最新回复，请无视这一篇。 DEL
家园 已合并于最新回复，请无视这一篇。 DEL