扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
作者：Arnon Rotem-Gal-Oz 来源：天极论坛整理 2007年10月13日
关键字：
| 以下是引用片段： 与非微内容(microcontent)的数据模型不匹配：ATOM数据模型很适合用于表示创作的(authored)内容或者微内容，诸如博客文章、链接列表、podcast、在线相册和日历事件等等。在这些情形中，每个Atom条目要有一个ID、一个标题、更新时间、若干作者和内容文本，这些需求都能够很好地满足，而且这样做很有道理。但另一方面，仍然有很多在线数据并不适合这个模型。 |
而且
| 以下是引用片段： 缺乏对条目(item)中的一个域(field)进行更新这种小粒度更新的支持：前面已经说过要实现对一个条目的编辑需要用新条目来替换整个旧条目。客户与服务器之间的交互的规定在当前APP草案的第5.4小节，后面作了一些摘录。 |
最后
| 以下是引用片段： 对分层结构的支持很弱：ATOM数据模型并不直接支持嵌套和分层。你可以有一个媒体资源或者资源条目的集合，但资源条目自身不能包含资源条目。也就是说，如果你想要表示一个含有子条目的条目，则子条目必须通过链接来引用，而不能内嵌在条目中。如果考虑到ATOM的博客联合(syndication)和博客编辑的背景，这样做是有道理的，比如在feed中或者编辑文章的时候把所有评论都直接包含在条目里，就不是一个好主意。但另一方面，当你要表示一个直接的父<->子层次关系，要是把子元素定义成一个独立的可定位资源，对客户来说就很繁琐，客户不得不总是发出两次甚至更多次调用才能得到所需的数据。 |
属于IETF APP工作组的Bill de hÓra对Dare的说法回应道：
| 以下是引用片段： 原则上讲，我很欢迎协议的实现者们根据他们的需要反过来推动ATOM协议的发展。然而，声称GData/APP已经失败实在是不知所云，特别是提到的问题，有些是被审慎地排除在设计目标之外的(就目前而言)。如果这些就是微软遇到最严重的问题，我会很惊讶于目前APP的总体设计情况良好。根据他的思考的深度和所提到的微软内部的讨论，我更惊讶于Dare竟然没有提到以下两个问题：1、更新的断点续传(Update resumption)：有的客户需要将数据分成小片段来上传的能力。除开用户体验和节省带宽的理由，这对有些收费方式来说也很重要;不然用户要为每次上传失败买单。APP从未涉及这个方面的支持;虽然用更普通的HTTP也可以做到，但要想得到合理的客户支持，你至少应该要求把它写进RFC。2、批量(batch)和multi-part更新：ATOM语法工作组已经考虑过这项特性但决定放弃。原因是要处理批量上传(或称作“打包运输(boxcarring)”)会变得难以预计的复杂。“发送一批条目”说起来很简单，但事实并非如此。不过未来仍然应该再继续考虑这些问题。 |
如果您非常迫切的想了解IT领域最新产品与技术信息，那么订阅至顶网技术邮件将是您的最佳途径之一。
京公网安备 11010802021500号