专利名称：：内容聚合平台的制作方法内容聚合平台
背景技术：
：RSS代表及eallySimpleSyndication(真正简单聚合)，是web内容聚合格式中的一种类型。RSSweb订阅源在web上越来越受欢迎，而且多种带RSS支持的软件应用程序也正在开发中。这些多种的应用程序可以具有许多可变特征，并且会引导用户安装几种不同的允许RSS的应用程序。每种RSS应用程序一般会具有其自身的订阅列表。当订阅列表较小时，用户在不同的应用程序间输入和管理这些订阅是相当容易的。然而，随着订阅列表的增长，结合这些不同的允许RSS的应用程序中的每一个来管理订阅变得非常困难。因此，订阅列表很容易变得不同步。此外，web订阅源有多种不同的文件格式，流行的是RSS0.91、0.92、1.0、2.0和Atom。每个允许RSS的应用程序必须支持这些格式中的大多数，并且在将来需要其支持的可能更多。为某些应用程序实现用于RSS环境的解析器会比其他更难。假定并非所有的应用程序开发者都是拥有与每种复杂的格式有关的经验和知识的RSS专家，则所有的开发者就不太可能都能正确地实现解析器。因此可以给出大量的文件格式，某些应用程序开发者将不会选择在此空间内开发应用程序，或者如果他们这样做了，这些应用程序则不会被配置用以完全利用在不同文件格式之间都可用的所有特征。RSS和web订阅源的另一方面是有关内容的发布。例如，拥有网络日志(weblog)的用户数目在增加。有许多提供免费网络日志服务的公共可用服务。然而，向网络日志服务发表内容可能是相当麻烦的，因为它可能涉及打开浏览器，导航到网络日志服务，登陆，接着键入条目并将其提交。许多应用程序开发者希望能从他们的特定应用程序中发表，而不是由于必须到某个网站而打断用户流程。此外，有许多不同类型的协议可以用于在客户端设备和特定服务之间通信。由此，应用程序开发者要实现所有的协议是不太可能的。因而用户体验将无法像它可以的那样完全。
发明内容诸如web内容聚合平台等内容聚合平台管理、组织从诸如因特网、内联网、专用网或其他计算设备等获取的内容并使之可用于消耗。在一些实施例中，平台可以获取并组织web内容，并使这种内容能由许多不同类型的应用程序消耗。这些应用程序可以必须理解特定的聚合格式，也可以不理解。应用程序编程接口(API)暴露对象模型，以允许应用程序和用户方便地完成诸如创建、读取、更新、删除订阅源等许多不同的任务。此外，平台可以提取特定的订阅源格式以提供提高进入平台的订阅源数据的可用性的通用格式。另外，平台以可使得附件对知道聚合的应用程序和不知道聚合的应用程序都可消耗的方式来处理和管理经由web订阅源接收到的附件。图1是根据一个实施例示出的包括web内容聚合平台的一系统的高级框图。图2是根据一个实施例示出的对象模型的各方面的框图。图3是根据一个实施例示出的订阅源同步引擎的框图。图4根据一个实施例示出了一示例性订阅源存储器。图5根据一个实施例示出了一示例性用户档案。图6根据一个实施例示出了一示例性对象。图7根据一个实施例示出了一示例性对象。具体实施例方式概述描述了一种诸如web内容聚合平台的内容聚合平台，该平台用于管理、组织从诸如因特网、内联网、专用网络或其他计算设备等获取的内容，并使之可用于消耗。在本发明的上下文(context)中，平台是在被设计用于RSSweb订阅源的上下文中使用的RSS平台的上下文中描述的。应该理解RSS上下文仅是一个示例，并不旨在将所作权利要求的主题的应用仅限为RSS上下文。以下描述假设读者比较熟悉RSS。关于RSS的背景，存在公开可用规范可以向感兴趣的读者提供信息。在本发明中，某些术语会在所描述的RSS实施例的上下文中使用。项目(item)是订阅源的基本单位。项目通常表示带有指向网站上实际文章的链接的网络日志条目或者新的文章/摘要。附件(enclosure)类似于电子邮件附件，除了它有指向实际内容的链接之外。订阅源(feed)是资源内的项目列表，通常仅是最近增加的。系统订阅源列表(systemfeedlist)是用户订阅的订阅源的列表。订阅(subscription)是指签字参加以接收新订阅源项目的通知的动作。在本发明所描述的各个实施例中，平台可以获取和组织web内容，并且使得这种内容可以由许多不同类型的应用程序可用于消耗。这些应用程序可以不必须理解特定的聚合格式，也可以不理解。因此，在实施示例中，不理解RSS格式的应用程序仍然可以通过平台来获取和消耗由平台通过RSS订阅源获取的诸如附件的内容。平台包括暴露对象模型的应用编程接口(API)，从而允许应用程序和用户方便地完成诸如创建、读取、更新、删除订阅源等许多不同的任务。例如，使用API,许多不同类型的应用程序就能够访问、管理和消耗包括订阅源的列表的订阅源列表。在至少一个实施例中，平台提供多个不同的订阅源解析器，每个解析器可以解析其中可能接收到web订阅源的特定格式。解析所得的格式随后会被转换成接着可由应用程序和用户利用的通用格式(commonformat)。通用格式被用于提取由任何一个特定格式具体化的特定概念以得到更为通用的、可理解的格式。此外，平台以可使得附件对知道聚合的应用程序和不知道聚合的应用程序都可消耗的方式来处理和管理经由web订阅源接收到的附件。在至少一些实施例中，API允许发现附件及其相关联的订阅源项目之间的关系。在以下的讨论中，首先在题目为"web内容聚合平台"之下描述一示例性平台及其组件。在该讨论之后，一实现的示例(在题目"实施示例"之下)被提供，并描述暴露对象模型的一组API，从而使得应用程序和用户能够以一种有意义并强有力的方式与平台交互。Web内容聚合平台图1根据一个实施例在100处总地示出了一个示例性系统。系统100的各方面可以结合任何适用的硬件、软件、固件及其组合实现。在至少一个实施例中，系统的各方面被实现为驻留在某些类型的计算机可读介质上的计算机可读指令。在该示例中，系统100包括内容聚合平台102和应用程序104的集合，其中的每个独立个体都可被配置成以不同的方式来利用平台，这在下文中会变得显而易见。在至少一些实施例中，内容聚合平台包括web内容聚合平台。在以下的讨论中，在RSS平台的上下文中描述平台102。应该理解这仅是一个示例，而非旨在将所作权利要求的主题的应用仅限制在RSS环境。相反地，所描述的实施例的原理可以用在其他环境中，而不背离所作权利要求的主题的精神和范围。在该示例中，平台102包括由一组API暴露的对象模型106，使得应用程序1()4可以与平台交互。提供了同步引擎108并将其配置成获取web内容，并且至少在某些实施例中将web内容转换成所谓的通用格式，将在随后对其做出更详细的描述。发布引擎110允许用户以经由API提取用于在用户的应用程序或计算设备和服务器或要接收内容的目标软件之间通信的通信协议的方式发布诸如网络日志的内容。此外，在至少一个实施例中，平台102包括存储订阅源列表114和订阅源数据116两者的订阅源存储112。此外，平台102在至少一个实施例中利用文件系统118来存储和维护附件120。使用文件系统有其优点，其中包括能让不必须理解聚合格式的应用程序消耗可能感兴趣的附件。此外，平台102包括持有要到特定web可访问位置上发帖的贴子(post)数据124的贴子队列122。如上所述，平台102可以使得应用程序访问、消耗和发布web内容。因此，应用程序104集合可以包括许多不同的应用程序。在至少一些实施例中，应用程序的类型可以包括那些知道聚合的应用程序和那些不知道聚合的应用程序。"知道聚合"是指应用程序至少有些熟悉所使用的聚合格式。因此，在RSS上下文中，知道聚合的应用程序是可以被配置成处理数据或在其他方面与以RSS格式表示的内容交互的应用程序。这可以包括拥有解析的能力并与RSS格式数据有意义地交互。类似地，不知道聚合的应用程序一般不被配置成理解聚合格式。然而，如将在下文中显而易见的，不知道聚合的应用程序仍可以通过平台访问和消耗以聚合格式到达平台的内容。更具体地考虑可以与平台交互的不同类型的应用程序，集合104包括web浏览器应用程序122、RSS阅读器应用程序124、数字图像库应用程序126、媒体播放器应用程序128和网络日志服务130。在该示例中，RSS阅读器应用程序124是知道聚合的应用程序，而媒体播放器128无需是知道聚合的应用程序。此外，web浏览器应用程序122可以是知道聚合的应用程序，也可以不是。当然，这些应用程序仅是不同类型可与平台交互的应用程序的示例。同样地，也可以使用与以上所示相同或不同的其他类型的应用程序，而不背离所作权利要求的主题的精神和范围。作为示例而非限制，这些其他类型的应用程序可以包括用于事件订阅源的日历应用程序、用于联系人订阅源的社交网络和电子邮件应用程序、用于图片订阅源的屏幕保护应用程序。用于文档订阅源的CRM等。在以下讨论中，将更详细地在其自己的标题下描述平台102的各独立组件的各方面。对象模型图2根据一个实施例示出了对象模型106的各独立对象。要描述的对象模型仅是可以使用的对象模型的一个示例，而非旨在限制将所作权利要求的主题的应用仅限为以下所描述的对象模型。如上所述，对象模型由API暴露，以下描述了它的一个示例。在该特定的对象模型中，提供了被称为订阅源的顶层对象200。订阅源对象200具有被称为订阅的类型文件夹的属性。订阅或文件夹对象202被建模为文件夹分层结构。由此，在该特定实施例中，订阅源或文件夹对象对象具有包括类型文件夹的子文件夹204和类型订阅源的订阅源206的属性。在订阅源对象206之下的是类型项目的项目对象208，而在项目对象206下是类型对象的附件对象210。对象模型的各独立对象具有可用于管理由平台接收的web内容的属性、方法和事件(在某些情况下)。上述对象模型允许使用分层结构来进行诸如管理订阅源列表之类的事件。例如，平台可以使用文件夹结构来执行一组订阅源。本领域的技术人员会理解，这为应用程序的开发者带来了方便。例如，执行一组订阅源提供了刷新位于新文件夹中的所有"新闻"订阅源的能力。作为一个示例，考虑以下情况。假设用户希望和与他们未实际订阅的订阅源相关联的数据交互或消耗该数据。对于被订阅的订阅源，即对于他们在根层的订阅文件夹中被表示的那些订阅源而言，同步引擎108(图1)会拾取订阅源，并以适当的时间间隔开始读取与订阅源相关联的数据。然而也存在使用平台的应用程序不希望被特定订阅源订阅这样的情况。相反地，应用程序只希望使用平台的功能来访问来自订阅源的数据。在这种情况下，在该特定的实施例中，订阅对象202支持一种允许下载订阅源而非订阅订阅源的方法。在该特定的示例中，应用程序调用该方法并向它提供与订阅源相关联的URL。平台于是使用URL来读取应用程序感兴趣的数据。这样，应用程序就能够以特定(adhoc)方式获取与订阅源相关联的数据，而甚至不用订阅该订阅源。进一步考虑对象模型，分别考虑项目和附件对象208和210。这里，这些对象很好地反映出RSS如何构建其自身。艮P，每个RSS订阅源具有在其内部能够可任选地出现附近的各独立项目。由此，对象模型的结构被配置用以反应该聚合格式的结构。从对象模型的角度看，项目主要有两种不同类型的方法和属性。第一种类型的方法/属性适合只读数据是，而第二种方法/属性适合可读写数据。作为第一种类型的方法属性的示例，考虑以下情况。每个订阅源可以具有用XML结构表示的与之相关联的数据。该数据包括诸如标题、作者、语言等这些事件。对象模型将这种数据作为只读对待。例如，由订阅源接收并与各独立项目相关联的数据一般被看作只读。这就防止了应用程序操作该数据。使用XML结构来表示订阅源数据也带来了如下的有点。假设同步引擎不理解己增加的新的XML元素。但是，同步引擎仍然能够存储元素及其相关联数据作为订阅源项目数据的部分。对于理解元素的那些应用程序而言，该元素及其关联数据仍然可由应用程序发现并消耗。另一方面，也存在被看作读/写数据的数据，诸如特定订阅源的名称。即，用户可能希望为他们特定的用户界面来个性化特定的订阅源。在这种情况下，对象模型具有读/写的属性。例如，用户可能希望将订阅源的名称从"NewYorkTimes"改成"NTY"。在这种情况下，名称属性可以是可读且可写的。订阅源同步引擎在所示和所描述的实施例中，订阅源同步引擎108(图l)负责从源下载RSS订阅源。源可以包括有关订阅源的任何合适的源，诸如网站、订阅源发布站点之类。在至少一个实施例中，任何适当的有效URL或资源标识符可以包括订阅源的源。同步引擎接收订阅源并处理各种订阅源格式，看管进度表，处理内容和附件下载并组织存档活动。图3根据一个实施例更为详尽地示出了一示例性订阅源同步引擎108。在该实施例中，同步引擎包括订阅源格式模块300、订阅源进度表模块302、订阅源内容下载模块304、附件下载模块306和存档模块308。应该理解为了清楚地描述他们特定的功能，所示这些模块在逻辑上是分开的模块。这些逻辑上分开的模块并不旨在将所作权利要求的主题仅限制到在本申请中所描述的特定结构或体系结构。订阅源格式模块——300在所示和所描述的实施例中，订阅源能够接收多个不同的订阅源格式。作为示例而非限制，这些订阅源格式可以包括RSS1.0、U、.9x、2.0、Atom.3等。同步引擎经由订阅源格式模块接收各种格式下的这些订阅源、解析格式并将格式转换成被称为通用格式的标准化格式。通用格式本质上是所有支持格式的超集。使用通用格式的好处之一是知道格式的应用程序现在只需要知道一种格式，即通用格式。此外，对被转换成通用格式的内容进行管理要容易地多，因为平台仅需要关心一种格式而非几种格式。此外，随着将来开发出其他的聚合格式，订阅源格式模块可适于处理该格式，而同时允许完全不知道新格式的应用程序仍然能利用和使用经由新格式到达平台的内容。关于通用格式，考虑以下情况。从格式的角度看，通用格式由在不同格式之间通用的XML方案表示。在不同的格式中，某些元素可以具有不同的名称、位于XML格式的分层结构中不同的位置等。相应地，通用格式是为了表示从所有可能的不同格式共同得出的通用结构和语法。由此，在某些情况下，来自一种格式的元素会被映射到通用格式的元素中。订阅源进度表模块——302每个订阅源可以具有何时同步引擎108应该检查以确定是否有新的内容可用的其自身的进度表。相应地，同步引擎通过订阅源进度表模块302来管理这些进度表来考虑站点的以及用户的或系统的要求和限制。作为一个示例，考虑以下情况。当首先下载订阅源时，更新进度表(即更新订阅源时的进度表)可被包括在订阅源的报头中。在这种情况下，订阅源进度表模块302为该特定的订阅源维持该更新的进度表，并根据该更新的进度表检查新的内容。然而，如果不包括进度表信息，那么订阅源进度表模块可以使用默认进度表来检查新的内容。任何适当的默认进度表可以用作诸如每24个小时重新下载订阅源内容。在至少一些实施例中，用户可以指定默认的工作进度表。此外，在至少某些实施例中，订阅源进度表模块可以支持被称为最小进度表的进度表。最小进度表是指定义更新之间时间段的最小更新时间。即，平台不会比最小进度表定义的更频繁地更新订阅源。在至少一些实施例中，用户可以改变最小时间。此外，用户也可以对任一或所有订阅源启动手动刷新。除了支持默认和最小进度表之外，在至少某些实施例中，订阅源进度表模块可以支持发布人指定的进度表。如同名称所暗示的，发布人指定的进步表是特定发布人指定的进度表。例如，发布人指定的进度表典型地能够指定还有多少分钟客户端才应该下一次更新该订阅源。这也可以使用RSS0.9x/2.0"tt"元素指定。同步引擎应该直到经过了这些分钟之后才读取订阅源的新副本。发布人指定的进度表也可以按诸如每小时、每天、每周的不同间隔尺寸级别来指定。应该注意订阅源文档的每个副本可以具有不同的发布人指定的进度表。例如，在白天，发布人可以提供15分钟的进度表，而在夜间期间，发布人则可以提供1个小时的进度表。在该情况下，同步引擎在每次下载订阅源时更新其行为。此外，在至少某些实施例中，同步引擎经由订阅源进度表模块302支持跳过小时和天的概念。具体地，RSS0.9和2.0能够让服务器屏蔽某些天和小时，期间客户端不应该作出更新。在这种情况下，同步引擎考虑这些设置(如果由服务器设置)并且在那段时间内不更新订阅源。除了默认的、最小的和发布人指定的进度表之外，在至少某些实施例中，同步引擎支持用户指定的进度表和手动更新的概念。更具体地，基于每个订阅源，用户可以指定他们选择的进度表。从平台的角度看，用户指定的进度表可以同服务器指定的一样复杂。在这种情况下，平台经由订阅源进度表模块来维持从订阅源提取的最近进度表以及用户进度表。在至少某些实施例中，用户进度表总是覆盖发布人的进度表。此外，在任何时候，应用程序可以启动对所有订阅源或个别订阅源的强制更新。有关带宽和服务器的问题，考虑如下情况。依照一个实施例，设计同步引擎可以考虑两个相关的问题。首先，同步应该考虑到用户的带宽和CPU。第二，由于RSS平台的广泛使用，同步引擎应该考虑到它对服务器的影响。这两个问题对何时和如何下载订阅源都有影响。从何时下载订阅源的角度看，同步引擎可以依照以下考虑来设计。在服务器没有进度表且没有来自用户的任何其他指令时，同步引擎在它每隔多久更新的问题上应该非常保守。因此，在至少某些实施例中，默认进度表被设置为24小时。此外，为了保护用户的资源免受低效服务器的不利影响，可以强制最小进度表以便即使在服务器另行指定的情况下仍能防止过分频繁地更新同步引擎。此外，应该谨慎地管理登陆时(以及在通用时间间隔处的，例如从启动时间起每小时)的更新。应该延迟订阅源更新直至完成用户登陆后的指定时间段，并且应该略微地交错以防止每小时准点式的大量更新命中。这可以通过相对用户期望立刻进行所有的更新来平衡。此外，当服务器使用上述的跳过小时或跳过天的特征时，客户端不应该在延期时段过去后马上读取更新。代替地，客户端应该在读取内容前等待至多达15分钟的随机时间间隔。为了在这方面协助同步引擎，订阅源进度表模块302可以为每个订阅源维持状态，诸如新鲜和陈旧。"新鲜"的状态意味着基于发布人的进步表，订阅源是新鲜的。"陈旧"状态意味着发布人的进度表指示了更新，但同步引擎还没有完成更新。对最新内容感兴趣的客户端可以请求立即更新，并在可用时被通知。如果设置了该期望，那么同步引擎可以在更新内容时实现任意的延时，而非严格地根据进度表而损害用户和服务器。有关如何下载订阅源，考虑如下情况。在一个实施例中，同步引擎可以使用任务调度器来在预定时刻启动同步引擎程序。在完成同步引擎后，它用它应该再次启动同步引擎的下一次时间(即NextSyncEngineLaunchTime(下一次同步引擎启动时间))来更新任务进度表。当同步引擎启动时，它使得所有其NextUpdateTime(下一次更新时间)小于或等于currentTime(当前时间)的"挂起"订阅源列队等候，并接着如下处理它们。对于每个订阅源，跟踪以下特性LastUpdateTime(上次更新时间)、NextUpdateTime、(用分钟数指定的)Interval(间隔)禾卩Las伍rrorlnterval(上次错误间隔)。在成功地同步了订阅源结束时，订阅源的LastUpdateTime被设置成当前时间，而NextUpdateTime被设置成LastUpdateTime加上时间间隔加上随机值(时间间隔的1/10)。具体如下LiastUpdateTime=currentTimeNextUpdateTime=currentTime+Interval+Random(Interval*0.1)ErrorInterval=0Random(argument)(随机(自变量))被定义成1及其argument(自变量)之间的正值。例如Random(lO)返回0到10之间的浮动值。如果因为以下原因之一，同步订阅源失败HTTP4xxresponsecode(响应代码)'-HTTP5xxresponsecode(响应代码)；Winsock/networkerror(网络出错)；or(或者)HTTP200,butresponsebodyhasaparsingerror(notarecognizedfeedformat)(响应实体有解析错误(不是公认的订阅源格式))那么如下应用指数补偿算法LastUpdateTime=<unchanged>Error工nterval=min(max(Error工nterval*2,lmin),Interval)NextUpdateTime-currentTime+ErrorInterval+Random(Error工nterval*0.1)在完成了所有"挂起"订阅源的同步后，同步引擎判定是否有任一订阅源超过了其NextUpdateTime(NextUpdateTime<=currentTime)。如果有，那么就如同刚启动同步引擎一样来列队并处理那些"挂起"订阅源。如果有未完成的"挂起"订阅源，则同步引擎判定是否有任何其NextUpdateTime在当前时间的2分钟之内(currentTime+2min>=NextUpdateTime)的"soon-to-sync(将要同步)"订阅源。如果有任何"soon-to-sync"订阅源，那么同步引擎进程继续运行，并且将定时器设置为在NextUpdateTime时"醒来"，并处理"挂起"订阅源。如果没有"soon-to-sync"订阅源，那么NextSyncEngineLaunch被设置成带有最快NextUpdateTime的订阅源的NextUpdateTime。接着任务调度器被设置成NextSyncEngineLaunchTime，并且同步引擎进程结束。依照一个实施例，如果在队列中有若干个"挂起"订阅源，那么同步引擎可以并行地同步多个订阅源。然而，并行同步的数目应该是有限的，在某个时间段内执行多少个同步也应该是有限的，以便避免占尽网络带宽和处理器利用率。依照一个实施例，订阅源同步的定形经由令牌存储段(token-bucket)提供。在概念上，令牌存储段如下工作。*每1/r秒将令牌加入到存储段中。*存储段可以最多持有b个令牌；如果当令牌达到时存储段是满的，就将其丢弃；*当订阅源需要被同步时，从存储段中移出令牌并将订阅源同步。*如果没有令牌可用，那么订阅源就待在队列中，并且等待直至有令牌变得可用。这种方法允许多达b个订阅源的突发订阅源同步。同步终究被限制为恒速r。在实现示例中，同步引擎为b和r使用以下值b-4且r二2。订阅源内容下载模块——304依照一个实施例，订阅源内容下载模块304处理下载订阅源并将新的订阅源项目与现有订阅源数据合并的进程。作为如何实现订阅源内容下载模块的示例，考虑如下情况。在适当的时候，同步引擎经由订阅源内容下载模块连接到服务器并下载适当的内容。依照一个实施例，平台被配置成支持不同的协议以下载内容。例如，同步引擎可以支持经HTTP下载订阅源文档。此外，同步引擎可以支持加密的HTTPURL(例如SSL、https等)。同样地，同步引擎也可以支持使用HTTPgzip支持的压縮，并支持从通用命名标准(UNC)中共享的订阅源下载。此外，同步引擎经由订阅源内容下载模块可以支持各种类型的认证。例如，同步引擎可以存储每个订阅源的用户名/密码，并可以使用用于HTTP基本认证的该用户名/密码来检索订阅源文档。有关更新订阅源，考虑如下情况。为了判定订阅源是否有新的内容，同步引擎为每个订阅源保存如下信息片段由对HTTP响应的上次修改的报头所报告的上次修改订阅源的时间；*上次HTTP响应中Etag报头的值；以及*订阅源最近pubDate的值(即订阅源级发布日期和时间)。如果站点支持Etag或上次修改，那么同步引擎可以使用这些来检査是否有新内容。站点可以使用HTTP响应代码304来响应，以指示没有新内容。否则，就下载内容。例如，如果站点支持RFC3229-for-feeds，那么站点可以基于客户端传递的Etag仅返回新的内容。不管使用那种方式，客户端接着将新内容与已存储的内容合并。作为如何能够下载订阅源内容的一个实施示例更为详细的描述，考虑如下情况。为了判定特定的站点是否己被改变，同步引擎可以提交带有如下信息的请求*如果客户端有保存的Etag,则是If－None－Match(若无匹配)报头；O带有以下值的报头A-IM:订阅源、gzip(用于RFC3229-for-feeds);*如果客户端有保存的上次修改的值，则是If－Modified－Since(若自前有修改)报头。如果服务器用HTTP响应代码304响应，则内容尚未被改变，且进程在这里结束。如果服务器用内容(即HTTP代码200或206)响应，则将下载的内容与本地内容合并(注意代码206指服务器支持RFC3229-for-feeds,而所下载的内容仅是新内容)。如果内容可用且如果同步引擎有己存储的pubDate，并且下载的订阅源文档包含信道级别pubDate元素，那么就比较这两个日期。如果本地pubDate与下载的pubDate相同，那么内容还没有被更新。于是可以丢弃下载的订阅源文档。如果同步引擎每次处理一个项目，那么就将每个项目的pubDate与同步引擎存储(如果有的话)的pubDate作比较，并丢弃较老的项目。接着将每个项目与存储中的项目作比较。比较应该使用引导元素(如果存在的话)或者链接元素(如果不存在引导)。如果发现匹配，那么新项目的内容就替换老项目的内容(如果两者都有pubDate，那么就用它来判定哪个更加新，否则最近下载的是新的)。如果没有发现匹配，那么预先挂起新的项目到存储的订阅源内容中(维持"最近在上"的语义)。如果在本地订阅源中增加或更新了任何项目，那么就认为订阅源是经更新的，并且通知RSS平台的客户端。对于出错情况，考虑如下各项。如果服务器用代码500或最多400个出错响应，那么就重置同步进度表并且服务器稍后再试。然而HTTP错误410应该被当作将更新进度表重置为"不再更新"的指示。随后应该重定向HTTP级别，但不应对客户端配置作出改变(存在几种偶然地作出重定向的不合理情况)。如果服务器用XML重定向来响应，那么应该重定向订阅源，并且向订阅源存储的URL应该被自动更新。这是客户端自动更新订阅源URL的唯一情况。对于下载订阅源，当用户参与其他任务时，下载不应该中断机器的普通使用(例如，带宽或CPU)。此外，在依赖于内容的交互式应用程序中，用户应该能够尽快地获取内容。附件下载模块一一306依照一个实施例，附件下载模块306负责为订阅源下载附件文件并应用适当的安全区。在下载订阅源内容时，也下载附件。可以用几种不同的方式处理下载附件。首先，认为基本附件时RSS2.0风格的附件。对于基本附件。同步引擎会经由附件下载模块306为附件链接而自动解析下载的订阅源。同步引擎被配置成支持多个基本附件。使用附件链接，附件下载模块于是可以下载附件。在至少某些实施例中，对于任何新的订阅源，默认的动作是不下载基本附件。使用暴露上述对象模型的API，客户端可以作出诸如基于每个订阅源将其行为改变为例如总是下载附件或强制下载特定订阅源中特定项目的特定附件等的动作。可以通过使用上述通用格式提供增强的附件处理。具体地，至少在某些实施例中，通用格式为附件定义额外的功能。具体地，通用格式允许对特定内容的多种表示。这包括例如预览内容和默认内容的标准定义以及指示是否应该下载或流入附件的能力。此外，通用格式允许附件和内容表示上的任意元数据。对于任何新的订阅源，默认动作是下载任何附件的"预览"版本，该"预览"版本遵守例如每个项目10k的默认尺寸限制。使用API,客户端可以作出诸如基于每个订阅源改变行为等的动作。例如，可以将行为改变为总是下载订阅源中项目的"默认"版本或总是下载具有特定值的元数据元素的任何特定版本。这可以使用为每个附件提供"下载这个？"逻辑的客户端回叫信号来完成。此外，使用API，客户端可以强制立即下载特定订阅源中任意特定项目(或所有项目)的任何特定附件的任何特定表示。关于在附件下载过程中提供安全性，考虑以下情况。依照一个实施例，下载的附件使用WindowsXPSP2附件执行服务(SP2AES)功能。这种功能可以提供文件类型和基于区的安全性。例如，拥有文件名和区信息(即附件来自哪里)，AES可以指示是否要阻止、允许或提示。对于区持久性而言，当保存文件时，AES可以持续保存区信息，这样当随后被打开时，可以提示用户。以下的表格描述了动作映射的AES危险级别/区<table><row><column>危险级别</column><column>限制</column><column>因特网</column><column>内联网</column><column>本地</column><column>受信任</column></row><row><column>危险，例如EXE</column><column>阻止</column><column>提不</column><column>允许</column><column>允许</column><column>允许</column></row><row><column>适中/未知，例如DOC或FOO</column><column>提不</column><column>提75</column><column>允许</column><column>允许</column><column>允许</column></row><row><column>低，例如TXT或JPG</column><column>允许</column><column>允许</column><column>允许</column><column>允许</column><column>允许<table>在所示和所描述的实施例中，同步引擎将为它下载的每个附件调用一方法，例如::CheckPolicy。基于响应，同步引擎会进行以下之一的操作*阻止不保存(在订阅源文件中将其标记为失败)；*允许保存附件*提示保存，但是持续保存区信息。这意味着如果用户双击该文件，他们会得到"运行/不运行"提示。依照一个实施例，同步引擎会首先将附件保存到磁盘上，并且不会将附件下载到存储器中。保存到盘上触发基于过滤器的反病毒应用程序，并给予这些应用程序隔离附件的机会(如果他们选择)。存档模块——308依照一个实施例，存档模块308负责处理旧的订阅源数据。默认地，订阅源最多持有200个项目。当订阅源超过指定最大值时，存档模块会删除较老的订阅源项目。然而却不删除相关联的附件。订阅源存储器依照一个实施例，订阅源存储112(图1)持有两种类型的信息——订阅源列表114和订阅源数据116。作为一个示例，考虑图4。其中，订阅源列表114被具体化为订阅源列表的分层树结构400。订阅源数据116包括与特定订阅源相关联的数据。在该示例中，基于每个订阅源来排列订阅源数据116以包括项目和附件的集合402。有许多种可以实现订阅源存储的不同方式。在该特定实施例中，订阅源存储器包括文件系统的部分。这样做的理由之一涉及简单性。即在该实施例中，订阅源列表被简单地表示为其下可以有子目录和文件的常规目录。分层则被反映为常规文件系统分层。由此，诸如"新闻"和"网络日志"等的每个文件夹本质上是文件系统中带有子目录和文件的常规目录。在该特定示例中，存在表示订阅源订阅的特别文件类型。仅作为示例，考虑这种类型的文件有以下格式"xyz.stg"。.stg文件存储有关订阅源的所有数据。由此，你会有一个订阅源列表，诸如具体化为树型结构400的列表，且在每个订阅源(或文件)中的是订阅源数据。在所示和所描述的实施例中，使用结构化存储技术来实现.stg文件。结构化存储技术是公知的，并且为本领域的技术人员所理解。但作为简要的背景，考虑以下情况。结构化存储通过将单个文件作为对象的结构化集合(被称为存储和流)来处理，以提供COM形式的文件和数据的持久性。结构化存储的目的是减少性能损失以及与在不同文件中存储分开的各对象部分的开销。结构化存储提供了一种解决方案，即通过定义如何经由被称为复合文件的标准实现而将单个文件实体作为两种类型的对象(存储和流)的结构化集合来处理。这允许用户如同复合文件是单个文件而非分开对象的嵌套分级一样来与之交互并管理它。本领于的技术人员会理解，存储对象和流对象用作文件中的文件系统。结构化存储通过当新的对象被增加到复合文件中或现有对象尺寸增加时消除将文件完全地重写到存储器中的需求来解决性能问题。新的数据被写入到永久性存储的下一个可用位置，且存储对象更新它维持的指针表格来跟踪其存储对象和流对象的位置。因此，在所示和所描述的实施例中，使用结构化存储技术来实现.Stg文件，且订阅源存储顶上的API允许访问不同的流和存储。在该特定示例中，将每个RSS项目写入到一个流中。此外，报头流包含与特定订阅源相关联的信息，诸如标题、订阅、订阅源URL等。此外，另一流存储索引类型的元数据，从而允许出于包括快速将某物标记为可读/不可读、删除项目等目的而快速并有效地访问文件中的内容。文件系统——附件在所示和所描述的实施例中，附件不存储在结构化存储器中或作为订阅源数据的部分，如图l所示。相反地，附件被标识为其他应用程序和用户可能希望访问或操作的项目，诸如一个或一些图片。由此，在所示和所描述的实施例中，将附件写入到用户的特定档案中。但要维持附件和所关联的订阅源项目之间的链接。作为一个示例，考虑图5。一旦用户开始订阅订阅源，那么就将订阅源内容本地地存储在用户的档案下，在ApplicationData(应用程序数据)或Knownfolder(己知文件夹)"订阅源"中。订阅源列表和订阅源被存储在ApplicationData中，以便能够更好地控制订阅源列表的格式和订阅源。API被暴露(如下文将描述的)使得应用程序能够访问和管理订阅源。订阅源列表是用户订阅的一组订阅源。在该示例中，包括订阅源列表的文件位于C:\Users\<Username>\AppData\Roaming\Microsoft\RSS\文件包含订阅源的属性以及项目和附件属性(指向与项目相关联的文件的URL)。例如，订阅源"NTY"的文件位于C:\Users\<Username>\AppData\Roaming\Microsoft\RSS\NYT.stg在该示例中，由订阅源对附件进行分组，并且将其存储在Knownfolder"订阅源"中。这允许用户和其他应用程序方便地访问和使用已下载的文件。例如，用户订阅NPR订阅源并希望确保他们的媒体播放器应用程序能够自动地添加那些文件。这样做使得Knownfolder能让用户从媒体播放器浏览它并将其设置为监控的文件夹。附件具有订阅源和贴子的适当的元数据，使得应用程序可以访问相关联的贴子和订阅源。附件位于如下所示C:\Users\<Username>\Feeds\<Feedname>\写入用户的硬盘的每个附件会具有包含有关该附件的元数据的次级流(例如NTFS流)。作为示例而非限制，元数据可以包括附件所来自的订阅源、作者、指向订阅源项目的链接、描述、标题、发布日期和下载日期以及其他合适的元数据。发布引擎/贴子队列通常当人们写常规的网络日志贴子时，本质上正在写入的是RSS项目。这个RSS项目一般被发送到某种类型的服务器，该服务器维持帐号信息、网络日志的位置等。在这种情况下，发布引擎110(图1)被配置用以使得应用程序能够作出张贴或发布内容，而同时从应用程序提取用于与服务器通信的通信协议。因此，应用程序仅需要提供要张贴的数据或内容，而发布引擎会处理格式化以及将内容传递给适当的服务器的剩余任务。由于存在可使用的若干种不同的协议，因而从应用程序提取协议提供了在使得许多不同类型的应用程序能够利用发布功能的范围内提供了很大的灵活性。在所示和所描述的实施例中，发布引擎功能被实现为允许应用程序发布网络日志而无需知道用于与服务器通信的协议的API。因此，在该示例中，API具有一种创建新的贴子的方法，当调用该方法时就创建RSSItem(RSS项目)对象。该RSSItem对象则具有一种张贴方法，当调用该方法时，将内容(在该情况下为网络日志)存储在临时存储，即贴子队列122(图1)中。内容被存储在临时存储中是因为在创建网络日志时用户可能不在线。接着，当用户作出在线连接时，发布引擎110连接到适当的服务器，并使用适于服务器的协议来将网络日志上传到服务器上。实现示例在以下的描述中，描述了一组示例性API，仅作为提供人们如何实现和结构化API以实现上述功能的一个示例。应该理解也可以使用其他API而不背离所作权利要求的主题的精神和范围。所述API—般被具体化为驻留在某些类型的计算机可读介质上的计算机可读指令和数据。以下描述的API可用于操作用户订阅的订阅源组(系统订阅源列表)和订阅源的属性。此外，订阅源数据API(即项目和附件)提供对存储在订阅源存储器中的订阅源的访问以及对订阅源的对等下载。使用订阅源API，诸如web浏览器、媒体播放器、数字图像库应用程序等应用程序随后能够暴露它们经历内的订阅源数据。在要描述的示例中，API被实现为COM双重接口，使得API可用于脚本语言、管理的代码以及原始Win32(C十+)代码。图6根据一个实施例示出了顶层对象或接口Ifeed(接口订阅源)以及IFeedFolder(接口订阅源文件夹)对象或接口以及它们相关联的属性、方法和事件。在该示例中，IFeeds具有一个属性——作为IFeedFolder的订阅。它是所有订阅的根文件夹。对于根对象存在多种方法，诸如DeleteFeed()、DeeteFeedByGuid()、DeleteFolder()等。本示例中所感兴趣的是GetFeedByGuid()方法。该方法可以由应用程序调用以通过例如订阅源的GUID来访问特定的订阅源。因此，应用程序无需知道订阅源的分层排序。相反地，应用程序可以使用订阅源的GUID来使得平台能够读取该订阅源。此外，ExistFeed()方法按名称检查订阅源的存在。而ExistFeedByGuid()则按GUID检查订阅源的存在。GetFeed()方法按名称或按GUID来获取订阅源。IsSubscribed()方法能让应用程序或调用程序确定特定的订阅源是否被订阅。此外，IFeed对象也具有SubscriptionsNotifications(订阅通知)事件，它允许登记系统订阅源列表上改变的通知。如上所述，订阅的类型是IFeedFolder。IFeedFolder对象或接口本质上提供目录，并具有相似类型的属性，诸如Name(名称)、Parent(父代)、Path(路径)等。此外，IFeedFolder对象具有类型为IFeed的订阅源属性和类型为IFeedFolder的子文件夹属性。子文件夹属性属于即时文件夹(例如是导出分层结构的文件夹)下的文件夹集合，而订阅源属性属于特定文件夹中的实际订阅源。此外，IFeedFolder具有LastWriteTime(上次写入时间)属性，它指示上次将任何事写入到文件夹中的时间。该属性对于可能暂时还没有运行但是也需要查看订阅源平台并确定其状态使得(如果需要)它可以同步的应用程序有用。存在有关IFeedFolder的多种方法，其中一些属于创建订阅源(创建希望不具有的订阅源并将其增加到特定文件夹中)、创建子文件夹、删除文件夹或子文件夹等。图7根据一个实施例示出了额外对象及其相关联的方法。具体地示出了IFeed、Item和Ienclosure(接口对象)对象。首先从IFeed对象开始，考虑如下情况。如本领域的技术人员所理解的，许多与该对象相关联的属性来自RSS订阅源自身，例如Title(标题)、Url、Webmaster(Web管理员)、SkipHours(跳过小时)、SkipDays(跳过天数)、ManagingEditor(管理编辑器)、Homepage(主页)、ImageURL(图像URL)等。此外，有另一组感兴趣的属性，即具有所有作为订阅源部分的项目的集合的Itemsproperty(项目属性)以及提供所有附件所写入的实际目录的LocalEnclosurePath(本地附件路径)属性。由此，对于应用程序，后一种属性使得应用程序能够非常方便地访问附件。此外，该对象支持一小组方法，诸如Delete()和Download()等用于管理特定订阅源的方法。另外，该对象支持方法XML()，它以通用格式返回订阅源的XML。XML数据可以用于诸如创建订阅源的报纸观点等事物。Clone()返回未订阅的订阅源的副本。前进到Item对象，该对象具有一组表示常规RSS元素的属性，所述RSS元素例如Description(描述)、Url、Title(标题)、Author(作者)等。此外，有指回到相关联的实际订阅源的Parent(父代)属性，以及使得应用程序能够操作Id而非必须重复所有的项目的Id属性。此外，有Enclosures(附件)属性，它是类型为IEnclosure的项目的附件的集合。另外，IsRead(读了吗)属性使得应用程序能够指示是否读出了特定项目。前进到Enclosure对象，考虑以下情况。该对象具有包括Type(类型)属性(例如mp3)和描述特定附件的长度的Length(长度)属性的属性。对于特定的附件也有LocalAbsolutePath(本地绝对路径)。Download()允许应用程序下载和使用个别的附件。总结上述web内容聚合平台可用于管理、组织从因特网获取的内容，并使之可用于消耗。平台可以获取和组织web内容，并使这样的内容可由许多不同类型的应用程序用于消耗。这些应用程序可以必须理解特定的聚合格式，也可以不理解。应用程序编程接口(API)暴露对象模型，以允许应用程序和用户方便地完成诸如创建、读取、更新、删除订阅源等许多不同任务。此外，平台可以提取特定的订阅源格式，以提供促进进入平台的订阅源数据的可用性的通用格式。另外，平台以可使得附件对知道聚合的应用程序和不知道聚合的应用程序都可消耗的方式来处理和管理经由web订阅源接收到的附件。虽然使用特定于结构化特征和/或方法步骤的语言描述了本发明，但是应该理解在所附权利要求书中定义的本发明不是必须限于所描述的特定特征和步骤。相反地，所公开的特定特征和步骤是作为实现所作权利要求的本发明的优选形式。权利要求1.一种系统，包括一种或多种计算机可读介质；在所述一种或多种计算机可读介质上的计算机可读指令，当被执行时，所述计算机可读指令实现RSS平台，被配置用以接收并处理一种或多种格式的RSS数据；以及代码装置，被配置用以使得不同类型的应用程序能够访问由所述RSS平台接收并处理的RSS数据。2.如权利要求l所述的系统，其特征在于，所述RSS平台被配置用以接收并处理多种不同格式的RSS数据。3.如权利要求l所述的系统，其特征在于，所述RSS平台被配置用以接收并处理多种不同格式的RSS数据，并且其中所述RSS平台被配置用以将所述多种不同的格式转换成通用格式。4.如权利要求l所述的系统，其特征在于，所述不同类型的应用程序包括除RSS阅读器之外的应用程序。5.如权利要求1所述的系统，其特征在于，所述不同类型的应用程序包括不理解所述平台接收到的RSS数据的格式的应用程序。6.如权利要求1所述的系统，其特征在于，所述不同类型的应用程序包括不理解所述平台接收到的RSS数据的格式的应用程序，并且其中所述不同类型的应用程序包括web浏览器应用程序、电子邮件应用程序或媒体播放器应用程序中的一种或多种。7.如权利要求1所述的系统，其特征在于，所述不同类型的应用程序包括web浏览器应用程序、电子邮件应用程序或媒体播放器应用程序中的一种或多种。8.如权利要求1所述的系统，其特征在于，所述代码装置暴露在一对象模型中，在该对象模型中订阅源订阅被建模为分层文件夹，并且其中所述对象模型提供对订阅源订阅共享列表的访问。9.如权利要求l所述的系统，其特征在于，所述代码装置被配置用以使得未被订阅至订阅源的一个或多个应用程序能够访问由所述RSS平台接收并处理的关联RSS数据。10.—种系统，包括一种或多种计算机可读介质；在所述计算机可读介质上具体化的一组API，所述API组包括使得至少一个应用程序能够访问已被处理并存储在订阅源存储中的RSS数据的一种或多种方法；以及其中所述至少一个应用程序不理解所述RSS数据最初被具体化成的RSS格式。11.如权利要求IO所述的系统，其特征在于，所述一种或多种方法包括一种提供对其中存储有一个或多个附件的数据存储的访问的方法，以及一种能被用于发现附件及其关联订阅源项目之间关系的方法。12.如权利要求10所述的系统，其特征在于，所述一种或多种方法包括提供对多种不同类型的应用程序的访问的方法。13.如权利要求10所述的系统，其特征在于，所述一种或多种方法包括提供对多种不同类型的应用程序的访问的方法，并且其中所述多种不同类型的应用程序中至少有一种理解所述RSS数据最初被具体化成的RSS格式。14.如权利要求10所述的系统，其特征在于，所述一种或多种方法包括提供对多种不同类型的应用程序的访问的方法，并且其中所述多种不同类型的应用程序中至少有一种理解所述RSS数据最初被具体化成的RSS格式并包括RSS阅读器。15.如权利要求10所述的系统，其特征在于，所述一种或多种方法包括提供对多种不同类型的应用程序的访问的方法，并且其中所述多种不同类型的应用程序中至少有一种理解所述RSS数据最初被具体化成的RSS格式并包括web浏览器应用程序。16.如权利要求10所述的系统，其特征在于，所述一种或多种方法包括一种能让应用程序访问与所述应用程序未被订阅至的web订阅源相关联的数据。17.如权利要求10所述的系统，其特征在于，所述一种或多种方法包括将订阅源订阅建模为分层文件夹的方法。18.如权利要求10所述的系统，其特征在于，所述至少一种应用程序包括电子邮件应用程序。19.如权利要求10所述的系统，其特征在于，所述至少一种应用程序包括web浏览器应用程序。20.如权利要求10所述的系统，其特征在于，所述至少一种应用程序包括媒体播放器应用程序。全文摘要诸如web内容聚合平台的内容聚合平台管理、组织从因特网获取的内容，并使之可用于消耗。在至少某些实施例中，平台可以获取和组织web内容，并使得这种内容可由许多不同类型的应用程序用于消耗。这些应用程序可以必须理解特定的聚合格式，也可以不理解。应用程序编程接口(API)暴露对象模型，以允许应用程序和用户方便地完成诸如创建、读取、更新、删除订阅源等许多不同任务。文档编号G06F9/44GK101203832SQ200680018421公开日2008年6月18日申请日期2006年6月14日优先权日2005年6月21日发明者A·S·甘迪,B·A·摩根,C·科怀恩,E·J·帕蒂斯,J·T·金,S·O·林德赛,W·V·沃科什,W·古尔德申请人:微软公司