XEP-0134
小 (→XMPP是神圣的) |
(→保持简单的客户端) |
||
| 第52行： | 第52行： | ||
一个好的尊敬XMPP协议的例子是[http://xmpp.org/extensions/xep-0126.html 隐身]] [[XEP-0134#附录G:备注|8]]; 因为Jabber社区在某个时候曾经非正式地定义了<presence type='invisible'/>, 因为XMPP兼容性的原因那个协议被废弃了. 另一个例子是[http://xmpp.org/extensions/xep-0071.html XHTML-IM] [[XEP-0134#附录G:备注|9]], 它重用了[http://www.w3.org/TR/xhtml1 XHTML 1.0] [[XEP-0134#附录G:备注|10]] (分享给XMPP一个通用的XML根的一个结构化格式) 而不是[http://msdn.microsoft.com/library/en-us/dnrtfspec/html/rtfspec.asp 富文本格式(RTF)] [[XEP-0134#附录G:备注|11]] (一个不是源自XML的非结构化的格式). 更进一步的例子是"扩展的出席信息"协议(见[http://xmpp.org/extensions/xep-0119.html 扩展出席信息协议族] [[XEP-0134#附录G:备注|12]]), 它被建立于XEP-0060之上而不是重载<presence/>节. 译者注：XEP-0119已经被作者收回了，可见这也不是一个好的例子。 | 一个好的尊敬XMPP协议的例子是[http://xmpp.org/extensions/xep-0126.html 隐身]] [[XEP-0134#附录G:备注|8]]; 因为Jabber社区在某个时候曾经非正式地定义了<presence type='invisible'/>, 因为XMPP兼容性的原因那个协议被废弃了. 另一个例子是[http://xmpp.org/extensions/xep-0071.html XHTML-IM] [[XEP-0134#附录G:备注|9]], 它重用了[http://www.w3.org/TR/xhtml1 XHTML 1.0] [[XEP-0134#附录G:备注|10]] (分享给XMPP一个通用的XML根的一个结构化格式) 而不是[http://msdn.microsoft.com/library/en-us/dnrtfspec/html/rtfspec.asp 富文本格式(RTF)] [[XEP-0134#附录G:备注|11]] (一个不是源自XML的非结构化的格式). 更进一步的例子是"扩展的出席信息"协议(见[http://xmpp.org/extensions/xep-0119.html 扩展出席信息协议族] [[XEP-0134#附录G:备注|12]]), 它被建立于XEP-0060之上而不是重载<presence/>节. 译者注：XEP-0119已经被作者收回了，可见这也不是一个好的例子。 | ||
| − | === | + | ===保持客户端简单=== |
| + | |||
| + | ''背景'' | ||
| + | |||
| + | 几乎所有的Jabber技术都是在一个客户端-服务器架构里实现的. 虽然那不是必需的(存在一些端到端的XMPP应用), 它通常是个好主意. 除了其他因素, 一个客户端-服务器架构使得Jabber社区能够强制大部分的复杂性落在服务器和组件上, 从而也就保持了客户端的简单. 这个原则从开始的时候就贯穿于Jabber社区, 并且成为继续创新的一个重要基础. | ||
| + | |||
| + | ''意义'' | ||
| + | |||
| + | "保持客户端简单"有很多实现影响, 其中有这些: | ||
| + | |||
| + | :* 不必要的时候不嵌套协议(你定义的协议越多, 写一个客户端的难度越大). | ||
| + | :* 容易降级，这样更简单的客户端或更旧的客户端仍能参与网络. | ||
| + | :* 如果需要大规模的处理, 让服务器或组件处理它. | ||
| + | :* 除非绝对必要，不强加客户端额外的需求(类似XSLT处理器等). | ||
| + | |||
| + | ''示例'' | ||
| + | |||
| + | 一个好的保持客户端简单的例子是presence节: 客户端只发送<presence/>而服务器处理出席信息探测, 广播, 和适当的路由决策. 另一个例子是[[XEP-0045|多用户聊天]] [[XEP-0134#附录G:备注|13]]: 尽管该协议比较复杂, 它的写法能让旧的客户端加入和参与到MUC房间，即使他们不能理解更高级的MUC扩展. | ||
| + | |||
===重用现有的协议=== | ===重用现有的协议=== | ||
===模块化更好=== | ===模块化更好=== | ||
2013年3月21日 (四) 05:31的版本
本文的英文原文来自XEP-0134
XEP-0134: XMPP设计准则
| 摘要: | 本文定义了Jabber协议和其他扩展的智能设计的最佳实践. |
|---|---|
| 作者: | Peter Saint-Andre |
| 版权: | © 1999 - 2013 XMPP标准化基金会(XSF). 参见法律通告. |
| 状态: | 活跃 |
| 类型: | 信息 |
| 版本: | 1.1 |
| 最后更新日期: | 2004-12-09 |
注意: 这个信息规格定义了那些已被XMPP委员会和/或XSF董事会批准的最佳实践或协议范本. 对本协议实现是被鼓励的,最佳实践和协议范本适于部署到生产系统.
目录 |
简介
可扩展的消息和出席信息协议(XMPP)为在XMPP的核心XML流技术上的各种各样的应用提供了一个坚实的, 弹性的基础. 随着XMPP Core 1 和 XMPP IM 2 的升级从而进入互联网标准流程, 对建设基于XMPP的应用和扩展的兴趣更加速了. 不幸的是, 不是每一个希望建设公共或私有XMPP扩展的人都熟悉关键那些原有的Jabber技术开发者提出的设计准则或今天那些指导成功的基于XMPP的协议的设计. 因此尝试把那些由Jabber开发者和协议设计者拥有的经常是隐形的知识翻译成更加显性的策略和原则来让其他人遵守是有益的. (更多互联网协议设计的洞见, 参阅 RFC 3117 3.) 解释"Jabber方法"的最终结果希望在Jabber/XMPP社区内对好的协议设计实践有一个广泛和深入的理解.
准则
XMPP是神圣的
背景
当XMPP标准基金会(XSF) 4 提交 XMPP Core 和 XMPP IM 协议给互联网工程任务组(IETF) 5的时候, 它放弃了在Jabber社区开发的核心XML流技术上变更控制. 无论如何, XSF还是保留了定义XMPP扩展的权力; 此外, 那一权力不仅限于XSF, 因为任何人可以定义他们自己的公共或私有的XMPP扩展. 这些扩展通常使用结构化的XML数据格式，由一个唯一性的不同于当前被IETF或XSF保留的命名空间来限定.
意义
当我们说"XMPP是神圣的", 我们的意思是好的协议设计必须在XMPP的上下文内工作并且不需要修改核心协议. 事实是, 任何这类修改都需要由IETF来执行. 而且, 核心语义几乎提供了一个协议设计者需要的大部分语义. 如果你认为你需要定义一种新的顶级节(不同于 <message/>, <presence/>, 和 <iq/>) 或任何节的一个新的'type'属性值, 那么你需要再想想. 把XMPP视为一个传输层并且在那一层之上建立扩展(也就是说, 这暗示你在工作于高级结构的时候,不能(must not)修改基础， 例如理论上不能添加元素和属性到XMPP schemas，否则应用将忽略它们; 你应该在一个独立的命名空间定义你自有的扩展). 尊重XMPP的另一个含义是任何时候如果可能就使用结构化的数据格式(例如, 应用XML 1.0 6而不是二进制或纯文本格式). 最后, 如XMPP Core解释的, <presence/>节仅用于广播网络和通讯可用性; 更多高级的信息发布, 使用Publish-Subscribe 7.
示例
一个好的尊敬XMPP协议的例子是隐身] 8; 因为Jabber社区在某个时候曾经非正式地定义了<presence type='invisible'/>, 因为XMPP兼容性的原因那个协议被废弃了. 另一个例子是XHTML-IM 9, 它重用了XHTML 1.0 10 (分享给XMPP一个通用的XML根的一个结构化格式) 而不是富文本格式(RTF) 11 (一个不是源自XML的非结构化的格式). 更进一步的例子是"扩展的出席信息"协议(见扩展出席信息协议族 12), 它被建立于XEP-0060之上而不是重载<presence/>节. 译者注：XEP-0119已经被作者收回了，可见这也不是一个好的例子。
保持客户端简单
背景
几乎所有的Jabber技术都是在一个客户端-服务器架构里实现的. 虽然那不是必需的(存在一些端到端的XMPP应用), 它通常是个好主意. 除了其他因素, 一个客户端-服务器架构使得Jabber社区能够强制大部分的复杂性落在服务器和组件上, 从而也就保持了客户端的简单. 这个原则从开始的时候就贯穿于Jabber社区, 并且成为继续创新的一个重要基础.
意义
"保持客户端简单"有很多实现影响, 其中有这些:
- 不必要的时候不嵌套协议(你定义的协议越多, 写一个客户端的难度越大).
- 容易降级，这样更简单的客户端或更旧的客户端仍能参与网络.
- 如果需要大规模的处理, 让服务器或组件处理它.
- 除非绝对必要，不强加客户端额外的需求(类似XSLT处理器等).
示例
一个好的保持客户端简单的例子是presence节: 客户端只发送<presence/>而服务器处理出席信息探测, 广播, 和适当的路由决策. 另一个例子是多用户聊天 13: 尽管该协议比较复杂, 它的写法能让旧的客户端加入和参与到MUC房间，即使他们不能理解更高级的MUC扩展.
