專利名稱：：內(nèi)容聚合平臺(tái)的制作方法內(nèi)容聚合平臺(tái)
背景技術(shù)：
：RSS代表及eallySimpleSyndication(真正簡(jiǎn)單聚合)，是web內(nèi)容聚合格式中的一種類型。RSSweb訂閱源在web上越來(lái)越受歡迎，而且多種帶RSS支持的軟件應(yīng)用程序也正在開(kāi)發(fā)中。這些多種的應(yīng)用程序可以具有許多可變特征，并且會(huì)引導(dǎo)用戶安裝幾種不同的允許RSS的應(yīng)用程序。每種RSS應(yīng)用程序一般會(huì)具有其自身的訂閱列表。當(dāng)訂閱列表較小時(shí)，用戶在不同的應(yīng)用程序間輸入和管理這些訂閱是相當(dāng)容易的。然而，隨著訂閱列表的增長(zhǎng)，結(jié)合這些不同的允許RSS的應(yīng)用程序中的每一個(gè)來(lái)管理訂閱變得非常困難。因此，訂閱列表很容易變得不同步。此外，web訂閱源有多種不同的文件格式，流行的是RSS0.91、0.92、1.0、2.0和Atom。每個(gè)允許RSS的應(yīng)用程序必須支持這些格式中的大多數(shù)，并且在將來(lái)需要其支持的可能更多。為某些應(yīng)用程序?qū)崿F(xiàn)用于RSS環(huán)境的解析器會(huì)比其他更難。假定并非所有的應(yīng)用程序開(kāi)發(fā)者都是擁有與每種復(fù)雜的格式有關(guān)的經(jīng)驗(yàn)和知識(shí)的RSS專家，則所有的應(yīng)用程序開(kāi)發(fā)者就不太可能都能正確地實(shí)現(xiàn)解析器。因此可以給出大量的文件格式，某些應(yīng)用程序開(kāi)發(fā)者將不會(huì)選擇在此空間內(nèi)開(kāi)發(fā)應(yīng)用程序，或者如果他們這樣做了，這些應(yīng)用程序則不會(huì)被配置用以完全利用在不同文件格式之間都可用的所有特征。RSS和web訂閱源的另一方面是有關(guān)內(nèi)容的發(fā)布。例如，擁有網(wǎng)絡(luò)日志(weblog)的用戶數(shù)目在增加。有許多提供免費(fèi)網(wǎng)絡(luò)日志服務(wù)的公共可用服務(wù)。然而，向網(wǎng)絡(luò)日志服務(wù)發(fā)表內(nèi)容可能是相當(dāng)麻煩的，因?yàn)樗赡苌婕按蜷_(kāi)瀏覽器，導(dǎo)航到網(wǎng)絡(luò)日志服務(wù)，登陸，接著鍵入條目并將其提交。許多應(yīng)用程序開(kāi)發(fā)者希望能從他們的特定應(yīng)用程序中發(fā)表，而不是由于必須到某個(gè)網(wǎng)站而打斷用戶流程。此外，有許多不同類型的協(xié)議可以用于在客戶端設(shè)備和特定服務(wù)之間通信。由此，應(yīng)用程序開(kāi)發(fā)者要實(shí)現(xiàn)所有的協(xié)議是不太可能的。因而用戶體驗(yàn)將無(wú)法像它可以的那樣完全。
發(fā)明內(nèi)容諸如web內(nèi)容聚合平臺(tái)等內(nèi)容聚合平臺(tái)管理、組織從諸如因特網(wǎng)、內(nèi)聯(lián)網(wǎng)、專用網(wǎng)或其他計(jì)算設(shè)備等獲取的內(nèi)容并使之可用于消耗。在一些實(shí)施例中，平臺(tái)可以獲取并組織web內(nèi)容，并使這種內(nèi)容能由許多不同類型的應(yīng)用程序消耗。這些應(yīng)用程序可以必須理解特定的聚合格式，也可以不理解。應(yīng)用程序編程接口(API)暴露對(duì)象模型，以允許應(yīng)用程序和用戶方便地完成諸如創(chuàng)建、讀取、更新、刪除訂閱源等許多不同的任務(wù)。此外，平臺(tái)可以提取特定的訂閱源格式以提供提高進(jìn)入平臺(tái)的訂閱源數(shù)據(jù)的可用性的通用格式。另外，平臺(tái)以可使得附件對(duì)知道聚合的應(yīng)用程序和不知道聚合的應(yīng)用程序都可消耗的方式來(lái)處理和管理經(jīng)由web訂閱源接收到的附件。圖1是根據(jù)一個(gè)實(shí)施例示出的包括web內(nèi)容聚合平臺(tái)的一系統(tǒng)的高級(jí)框圖。圖2是根據(jù)一個(gè)實(shí)施例示出的對(duì)象模型的各方面的框圖。圖3是根據(jù)一個(gè)實(shí)施例示出的訂閱源同步引擎的框圖。圖4根據(jù)一個(gè)實(shí)施例示出了一示例性訂閱源存儲(chǔ)。圖5根據(jù)一個(gè)實(shí)施例示出了一示例性用戶簡(jiǎn)檔。圖6根據(jù)一個(gè)實(shí)施例示出了示例性對(duì)象。圖7根據(jù)一個(gè)實(shí)施例示出了示例性對(duì)象。具體實(shí)施例方式概述描述了一種諸如web內(nèi)容聚合平臺(tái)的內(nèi)容聚合平臺(tái)，該平臺(tái)用于管理、組織從諸如因特網(wǎng)、內(nèi)聯(lián)網(wǎng)、專用網(wǎng)絡(luò)或其他計(jì)算設(shè)備等獲取的內(nèi)容，并使之可用于消耗。在本發(fā)明的上下文(context)中，平臺(tái)是在被設(shè)計(jì)用于RSSweb訂閱源的上下文中使用的RSS平臺(tái)的上下文中描述的。應(yīng)該理解RSS上下文僅是一個(gè)示例，并不旨在將所作權(quán)利要求的主題的應(yīng)用僅限為RSS上下文。以下描述假設(shè)讀者比較熟悉RSS。關(guān)于RSS的背景，存在公開(kāi)可用規(guī)范可以向感興趣的讀者提供信息。在本發(fā)明中，某些術(shù)語(yǔ)會(huì)在所描述的RSS實(shí)施例的上下文中使用。項(xiàng)目(item)是訂閱源的基本單位。項(xiàng)目通常表示帶有指向網(wǎng)站上實(shí)際文章的鏈接的網(wǎng)絡(luò)日志條目或者新的文章/摘要。附件(enclosure)類似于電子郵件附件，除了它有指向?qū)嶋H內(nèi)容的鏈接之外。訂閱源(feed)是資源內(nèi)的項(xiàng)目列表，通常僅是最近增加的。系統(tǒng)訂閱源列表(systemfeedlist)是用戶訂閱的訂閱源的列表。訂閱(subscription)是指簽字參加以接收新訂閱源項(xiàng)目的通知的動(dòng)作。在本發(fā)明所描述的各個(gè)實(shí)施例中，平臺(tái)可以獲取和組織web內(nèi)容，并且使得這種內(nèi)容可以由許多不同類型的應(yīng)用程序可用于消耗。這些應(yīng)用程序可以不必須理解特定的聚合格式，也可以不理解。因此，在實(shí)施示例中，不理解RSS格式的應(yīng)用程序仍然可以通過(guò)平臺(tái)來(lái)獲取和消耗由平臺(tái)通過(guò)RSS訂閱源獲取的諸如附件的內(nèi)容。平臺(tái)包括暴露對(duì)象模型的應(yīng)用編程接口(API)，從而允許應(yīng)用程序和用戶方便地完成諸如創(chuàng)建、讀取、更新、刪除訂閱源等許多不同的任務(wù)。例如，使用API，許多不同類型的應(yīng)用程序就能夠訪問(wèn)、管理和消耗包括訂閱源的列表的訂閱源列表。在至少一個(gè)實(shí)施例中，平臺(tái)提供多個(gè)不同的訂閱源解析器，每個(gè)解析器可以解析其中可能接收到web訂閱源的特定格式。解析所得的格式隨后會(huì)被轉(zhuǎn)換成接著可由應(yīng)用程序和用戶利用的通用格式(commonformat)。通用格式被用于提取由任何一個(gè)特定格式具體化的特定概念以得到更為通用的、可理解的格式。此外，平臺(tái)以可使得附件對(duì)知道聚合的應(yīng)用程序和不知道聚合的應(yīng)用程序都可消耗的方式來(lái)處理和管理經(jīng)由web訂閱源接收到的附件。在至少一些實(shí)施例中，API允許發(fā)現(xiàn)附件及其相關(guān)聯(lián)的訂閱源項(xiàng)目之間的關(guān)系。在以下的討論中，首先在題目為"web內(nèi)容聚合平臺(tái)"之下描述一示例性平臺(tái)及其組件。在該討論之后，一實(shí)現(xiàn)的示例(在題目"實(shí)施示例"之下)被提供，并描述暴露對(duì)象模型的一組API，從而使得應(yīng)用程序和用戶能夠以一種有意義并強(qiáng)有力的方式與平臺(tái)交互。Web內(nèi)容聚合平臺(tái)圖1根據(jù)一個(gè)實(shí)施例在100處總地示出了一個(gè)示例性系統(tǒng)。系統(tǒng)100的各方面可以結(jié)合任何適用的硬件、軟件、固件及其組合實(shí)現(xiàn)。在至少一個(gè)實(shí)施例中，系統(tǒng)的各方面被實(shí)現(xiàn)為駐留在某些類型的計(jì)算機(jī)可讀介質(zhì)上的計(jì)算機(jī)可讀指令。在該示例中，系統(tǒng)100包括內(nèi)容聚合平臺(tái)102和應(yīng)用程序104的集合，其中的每個(gè)個(gè)體都可被配置成以不同的方式來(lái)利用平臺(tái)，這在下文中會(huì)變得顯而易見(jiàn)。在至少一些實(shí)施例中，內(nèi)容聚合平臺(tái)包括web內(nèi)容聚合平臺(tái)。在以下的討論中，在RSS平臺(tái)的上下文中描述平臺(tái)102。應(yīng)該理解這僅是一個(gè)示例，而非旨在將所作權(quán)利要求的主題的應(yīng)用僅限制在RSS環(huán)境。相反地，所描述的實(shí)施例的原理可以用在其他聚合環(huán)境中，而不背離所作權(quán)利要求的主題的精神和范圍。在該示例中，平臺(tái)102包括由一組API暴露的對(duì)象模型106，使得應(yīng)用程序104可以與平臺(tái)交互。提供了同步引擎108并將其配置成獲取web內(nèi)容等等，并且至少在某些實(shí)施例中將web內(nèi)容轉(zhuǎn)換成所謂的通用格式，將在隨后對(duì)其做出更詳細(xì)的描述。發(fā)布引擎110允許用戶以經(jīng)由API提取用于在用戶的應(yīng)用程序或計(jì)算設(shè)備和服務(wù)器或要接收內(nèi)容的目標(biāo)軟件之間通信的通信協(xié)議的方式發(fā)布諸如網(wǎng)絡(luò)日志的內(nèi)容。此外，在至少一個(gè)實(shí)施例中，平臺(tái)102包括存儲(chǔ)訂閱源列表114和訂閱源數(shù)據(jù)116兩者的訂閱源存儲(chǔ)112。此外，平臺(tái)102在至少一個(gè)實(shí)施例中利用文件系統(tǒng)118來(lái)存儲(chǔ)和維護(hù)附件120。使用文件系統(tǒng)有其優(yōu)點(diǎn)，其中包括能讓不一定理解聚合格式的應(yīng)用程序消耗可能感興趣的附件。此外，平臺(tái)102包括保存要到特定web可訪問(wèn)位置上發(fā)帖的貼子(post)數(shù)據(jù)124的貼子隊(duì)列122。如上所述，平臺(tái)102可以使得應(yīng)用程序訪問(wèn)、消耗和發(fā)布web內(nèi)容。因此，應(yīng)用程序104集合可以包括許多不同類型的應(yīng)用程序。在至少一些實(shí)施例中，應(yīng)用程序的類型可以包括那些知道聚合的應(yīng)用程序和那些不知道聚合的應(yīng)用程序。"知道聚合"是指應(yīng)用程序至少有些熟悉所使用的聚合格式。因此，在RSS上下文中，知道聚合的應(yīng)用程序是可以被配置成處理數(shù)據(jù)或在其他方面與以RSS格式表示的內(nèi)容交互的應(yīng)用程序。這可以包括擁有解析的能力并與RSS格式數(shù)據(jù)有意義地交互。類似地，不知道聚合的應(yīng)用程序一般不被配置成理解聚合格式。然而，如將在下文中顯而易見(jiàn)的，不知道聚合的應(yīng)用程序仍可以訪問(wèn)和消耗以聚合格式到達(dá)平臺(tái)的內(nèi)容。更具體地考慮可以與平臺(tái)交互的不同類型的應(yīng)用程序，集合104包括web瀏覽器應(yīng)用程序122、RSS閱讀器應(yīng)用程序124、數(shù)字圖像庫(kù)應(yīng)用程序126、媒體播放器應(yīng)用程序128和網(wǎng)絡(luò)日志服務(wù)130。在該示例中，RSS閱讀器應(yīng)用程序124是知道聚合的應(yīng)用程序，而媒體播放器128無(wú)需是知道聚合的應(yīng)用程序。此外，web瀏覽器應(yīng)用程序122可以是知道聚合的應(yīng)用程序，也可以不是。當(dāng)然，這些應(yīng)用程序僅是不同類型可與平臺(tái)交互的應(yīng)用程序的示例。同樣地，也可以使用與以上所示相同或不同的其他類型的應(yīng)用程序，而不背離所作權(quán)利要求的主題的精神和范圍。作為示例而非限制，這些其他類型的應(yīng)用程序可以包括用于事件訂閱源的日歷應(yīng)用程序、用于聯(lián)系人訂閱源的社交網(wǎng)絡(luò)和電子郵件應(yīng)用程序、用于圖片訂閱源的屏幕保護(hù)應(yīng)用程序、用于文檔訂閱源的CRM等。在以下討論中，將更詳細(xì)地在其自己的標(biāo)題下描述平臺(tái)102的各個(gè)組件的各方面。對(duì)象模型圖2根據(jù)一個(gè)實(shí)施例示出了對(duì)象模型106的各個(gè)對(duì)象。要描述的對(duì)象模型僅是可以使用的對(duì)象模型的一個(gè)示例，而非旨在限制將所作權(quán)利要求的主題的應(yīng)用僅限為以下所描述的對(duì)象模型。如上所述，對(duì)象模型由API暴露，以下描述了它的一個(gè)示例。在該特定的對(duì)象模型中，提供了被稱為訂閱源(feeds)的頂層對(duì)象200。訂閱源)對(duì)象200具有被稱為訂閱(subscriptions)的(類型為文件夾(folder))屬性。訂閱或文件夾(folder)對(duì)象202被建模為文件夾分層結(jié)構(gòu)。由此，在該特定示例中，訂閱或文件夾對(duì)象具有包括類型為文件夾(folder)的子文件夾(subfolders)204和類型為訂閱源(feed)的訂閱源(feeds)206的屬性。在訂閱源對(duì)象206之下的是類型為項(xiàng)目(item)的項(xiàng)目(item)對(duì)象208，而在項(xiàng)目對(duì)象206下是類型為對(duì)象(object)的附件(enclosures)對(duì)象210。對(duì)象模型的各個(gè)對(duì)象具有可用于管理由平臺(tái)接收的web內(nèi)容的屬性、方法和事件(在某些情況下)。上述對(duì)象模型允許使用分層結(jié)構(gòu)來(lái)進(jìn)行諸如管理訂閱源列表之類的事情。例如，平臺(tái)可以針對(duì)一組訂閱源使用文件夾結(jié)構(gòu)來(lái)執(zhí)行。本領(lǐng)域的技術(shù)人員會(huì)理解，這為應(yīng)用程序的開(kāi)發(fā)者帶來(lái)了方便。例如，針對(duì)一組訂閱源的執(zhí)行提供了刷新位于新文件夾中的所有"新聞"訂閱源的能力。作為一個(gè)示例，考慮以下情況。假設(shè)用戶希望和與他們未實(shí)際訂閱的訂閱源相關(guān)聯(lián)的數(shù)據(jù)交互或消耗該數(shù)據(jù)。對(duì)于被訂閱的訂閱源，即對(duì)于他們?cè)诟鶎拥挠嗛單募A中被表示的那些訂閱源而言，同步引擎108(圖1)會(huì)拾取訂閱源，并以適當(dāng)?shù)臅r(shí)間間隔開(kāi)始取與訂閱源相關(guān)聯(lián)的數(shù)據(jù)。然而也存在使用平臺(tái)的應(yīng)用程序不希望被訂閱到特定訂閱源這樣的情況。相反地，應(yīng)用程序只希望使用平臺(tái)的功能來(lái)訪問(wèn)來(lái)自訂閱源的數(shù)據(jù)。在這種情況下，在該特定的實(shí)施例中，訂閱對(duì)象202支持一種允許下載訂閱源而非訂閱訂閱源的方法。在該特定的示例中，應(yīng)用程序調(diào)用該方法并向它提供與訂閱源相關(guān)聯(lián)的URL。平臺(tái)于是使用URL來(lái)取應(yīng)用程序感興趣的數(shù)據(jù)。這樣，應(yīng)用程序就能夠以特定(adhoc)方式獲取與訂閱源相關(guān)聯(lián)的數(shù)據(jù)，而甚至不用訂閱該訂閱源。進(jìn)一步考慮對(duì)象模型，分別考慮項(xiàng)目和附件對(duì)象208和210。這里，這些對(duì)象很好地反映出RSS如何構(gòu)建其自身。gp，每個(gè)RSS訂閱源具有在其內(nèi)部能夠可任選地出現(xiàn)附件的各個(gè)項(xiàng)目。由此，對(duì)象模型的結(jié)構(gòu)被配置用以反應(yīng)該聚合格式的結(jié)構(gòu)。從對(duì)象模型的角度看，項(xiàng)目主要有兩種不同類型的方法和屬性。第一種類型的方法/屬性適合只讀數(shù)據(jù)，而第二種方法/屬性適合可讀寫數(shù)據(jù)。作為第一種類型的方法屬性的示例，考慮以下情況。每個(gè)訂閱源可以具有用XML結(jié)構(gòu)表示的與之相關(guān)聯(lián)的數(shù)據(jù)。該數(shù)據(jù)包括諸如標(biāo)題、作者、語(yǔ)言等這些內(nèi)容。對(duì)象模型將這種數(shù)據(jù)作為只讀對(duì)待。例如，由訂閱源接收并與各個(gè)項(xiàng)目相關(guān)聯(lián)的數(shù)據(jù)一般被看作只讀。這就防止了應(yīng)用程序操作該數(shù)據(jù)。使用XML結(jié)構(gòu)來(lái)表示訂閱源數(shù)據(jù)也帶來(lái)了如下的優(yōu)點(diǎn)。假設(shè)同步引擎不理解已增加的新的XML元素。但是，同步引擎仍然能夠存儲(chǔ)該元素及其相關(guān)聯(lián)數(shù)據(jù)作為訂閱源項(xiàng)目數(shù)據(jù)的一部分。對(duì)于理解該元素的那些應(yīng)用程序而言，該元素及其關(guān)聯(lián)數(shù)據(jù)仍然可由應(yīng)用程序發(fā)現(xiàn)并消耗。另一方面，也存在被看作讀/寫數(shù)據(jù)的數(shù)據(jù)，諸如特定訂閱源的名稱。即，用戶可能希望為他們特定的用戶界面來(lái)個(gè)性化特定的訂閱源。在這種情況下，對(duì)象模型具有讀/寫的屬性。例如，用戶可能希望將訂閱源的名稱從"NewYorkTimes"改成"NYT"。在這種情況下，名稱屬性可以是可讀且可寫的。訂閱源同步引擎在所示和所描述的實(shí)施例中，訂閱源同步引擎108(圖l)負(fù)責(zé)從源下載RSS訂閱源。源可以包括有關(guān)訂閱源的任何合適的源，諸如網(wǎng)站、訂閱源發(fā)布站點(diǎn)之類。在至少一個(gè)實(shí)施例中，任何適當(dāng)?shù)挠行RL或資源標(biāo)識(shí)符可以包括訂閱源的源。同步引擎接收訂閱源并處理各種訂閱源格式，看管進(jìn)度表，處理內(nèi)容和附件下載并組織存檔活動(dòng)。圖3根據(jù)一個(gè)實(shí)施例更為詳盡地示出了一示例性訂閱源同步引擎108。在該實(shí)施例中，同步引擎包括訂閱源格式模塊300、訂閱源進(jìn)度表模塊302、訂閱源內(nèi)容下載模塊304、附件下載模塊306和存檔模塊308。應(yīng)該理解為了清楚地描述他們特定的功能，所示這些模塊在邏輯上是分開(kāi)的模塊。這些邏輯上分開(kāi)的模塊并不旨在將所作權(quán)利要求的主題僅限制到在本申請(qǐng)中所描述的特定結(jié)構(gòu)或體系結(jié)構(gòu)。訂閱源格式模塊——300在所示和所描述的實(shí)施例中，訂閱源能夠以多個(gè)不同的訂閱源格式來(lái)接收。作為示例而非限制，這些訂閱源格式可以包括RSS1.0、1.1、.9x、2.0、Atom.3等。同步引擎經(jīng)由訂閱源格式模塊接收各種格式下的這些訂閱源、解析格式并將格式轉(zhuǎn)換成被稱為通用格式的標(biāo)準(zhǔn)化格式。通用格式本質(zhì)上是所有支持格式的超集。使用通用格式的好處之一是知道格式的應(yīng)用程序現(xiàn)在只需要知道一種格式，即通用格式。此外，對(duì)被轉(zhuǎn)換成通用格式的內(nèi)容進(jìn)行管理要容易地多，因?yàn)槠脚_(tái)僅需要關(guān)心一種格式而非幾種格式。此外，隨著將來(lái)開(kāi)發(fā)出其他的聚合格式，訂閱源格式模塊可適于處理該格式，而同時(shí)允許完全不知道新格式的應(yīng)用程序仍然能利用和使用經(jīng)由新格式到達(dá)平臺(tái)的內(nèi)容。關(guān)于通用格式，考慮以下情況。從格式的角度看，通用格式由在不同格式之間通用的XML模式表示。在不同的格式中，某些元素可以具有不同的名稱、位于XML格式的分層結(jié)構(gòu)中不同的位置等。相應(yīng)地，通用格式是為了表示從所有可能的不同格式共同得出的通用結(jié)構(gòu)和語(yǔ)法。由此，在某些情況下，來(lái)自一種格式的元素會(huì)被映射到通用格式的元素中。訂閱源進(jìn)度表模塊——302每個(gè)訂閱源可以具有何時(shí)同步引擎108應(yīng)該檢查以確定是否有新的內(nèi)容可用的其自身的進(jìn)度表。相應(yīng)地，同步引擎通過(guò)訂閱源進(jìn)度表模塊302來(lái)管理這些進(jìn)度表來(lái)考慮站點(diǎn)的以及用戶的或系統(tǒng)的要求和限制。作為一個(gè)示例，考慮以下情況。當(dāng)首先下載訂閱源時(shí)，更新進(jìn)度表(即何時(shí)更新訂閱源的進(jìn)度表)可被包括在訂閱源的報(bào)頭中。在這種情況下，訂閱源進(jìn)度表模塊302為該特定的訂閱源維持該更新進(jìn)度表，并根據(jù)該更新進(jìn)度表檢査新的內(nèi)容。然而，如果不包括進(jìn)度表信息，那么訂閱源進(jìn)度表模塊可以使用默認(rèn)進(jìn)度表來(lái)檢查新的內(nèi)容。任何適當(dāng)?shù)哪J(rèn)進(jìn)度表可以使用，諸如每24個(gè)小時(shí)重新下載訂閱源內(nèi)容。在至少一些實(shí)施例中，用戶可以指定不同的默認(rèn)的工作進(jìn)度表。此外，在至少某些實(shí)施例中，訂閱源進(jìn)度表模塊可以支持被稱為最小進(jìn)度表的進(jìn)度表。最小進(jìn)度表是指定義更新之間時(shí)間段的最小更新時(shí)間。即，平臺(tái)不會(huì)比最小進(jìn)度表定義的更頻繁地更新訂閱源。在至少一些實(shí)施例中，用戶可以改變最小時(shí)間。此外，用戶也可以對(duì)任一或所有訂閱源啟動(dòng)手動(dòng)刷新。除了支持默認(rèn)和最小進(jìn)度表之外，在至少某些實(shí)施例中，訂閱源進(jìn)度表模塊可以支持發(fā)布人指定的進(jìn)度表。如同名稱所暗示的，發(fā)布人指定的進(jìn)度表是特定發(fā)布人指定的進(jìn)度表。例如，發(fā)布人指定的進(jìn)度表典型地能夠指定還有多少分鐘客戶端才應(yīng)該下一次更新該訂閱源。這可以使用RSS0.9x/2.0"ttl"元素指定。同步引擎應(yīng)該直到經(jīng)過(guò)了這些分鐘之后才取訂閱源的新副本。發(fā)布人指定的進(jìn)度表也可以按諸如每小時(shí)、每天、每周的不同間隔尺寸級(jí)別來(lái)指定。應(yīng)該注意訂閱源文檔的每個(gè)副本可以具有不同的發(fā)布人指定的進(jìn)度表。例如，在白天，發(fā)布人可以提供15分鐘的進(jìn)度表，而在夜間期間，發(fā)布人則可以提供l個(gè)小時(shí)的進(jìn)度表。在該情況下，同步引擎在每次下載訂閱源時(shí)更新其行為。此外，在至少某些實(shí)施例中，同步引擎經(jīng)由訂閱源進(jìn)度表模塊302支持跳過(guò)小時(shí)和天的概念。具體地，RSS0.9和2.0能夠讓服務(wù)器屏蔽某些天和小時(shí)，期間客戶端不應(yīng)該作出更新。在這種情況下，同步引擎考慮這些設(shè)置(如果由服務(wù)器設(shè)置)并且在那段時(shí)間內(nèi)不更新訂閱源。除了默認(rèn)的、最小的和發(fā)布人指定的進(jìn)度表之外，在至少某些實(shí)施例中，同步引擎支持用戶指定的進(jìn)度表和手動(dòng)更新的概念。更具體地，基于每個(gè)訂閱源，用戶可以指定他們選擇的進(jìn)度表。從平臺(tái)的角度看，用戶指定的進(jìn)度表可以同服務(wù)器指定的一樣復(fù)雜。在這種情況下，平臺(tái)經(jīng)由訂閱源進(jìn)度表模塊來(lái)維持從訂閱源提取的最近進(jìn)度表以及用戶進(jìn)度表。在至少某些實(shí)施例中，用戶進(jìn)度表總是覆蓋發(fā)布人的進(jìn)度表。此外，在任何時(shí)候，應(yīng)用程序可以啟動(dòng)對(duì)所有訂閱源或個(gè)別訂閱源的強(qiáng)制更新。有關(guān)帶寬和服務(wù)器的問(wèn)題，考慮如下情況。依照一個(gè)實(shí)施例，設(shè)計(jì)同步引擎可以考慮兩個(gè)相關(guān)的問(wèn)題。首先，同步應(yīng)該考慮到用戶的帶寬和CPU。第二，由于RSS平臺(tái)的廣泛使用，同步引擎應(yīng)該考慮到它對(duì)服務(wù)器的影響。這兩個(gè)問(wèn)題對(duì)何時(shí)和如何下載訂閱源都有影響。從何時(shí)下載訂閱源的角度看，同步引擎可以依照以下考慮來(lái)設(shè)計(jì)。在服務(wù)器沒(méi)有進(jìn)度表且沒(méi)有來(lái)自用戶的任何其他指令時(shí)，同步引擎在它每隔多久更新的問(wèn)題上應(yīng)該非常保守。因此，在至少某些實(shí)施例中，默認(rèn)進(jìn)度表被設(shè)置為24小時(shí)。此外，為了保護(hù)用戶的資源免受低效服務(wù)器的不利影響，可以強(qiáng)制最小進(jìn)度表以便即使在服務(wù)器另行指定的情況下仍能防止同步引擎過(guò)分頻繁地進(jìn)行更新。此外，應(yīng)該謹(jǐn)慎地管理登陸時(shí)(以及在通用時(shí)間間隔處的，例如從啟動(dòng)時(shí)間起每小時(shí))的更新。應(yīng)該延遲訂閱源更新直至完成用戶登陸后的指定時(shí)間段，并且應(yīng)該略微地交錯(cuò)以防止每小時(shí)準(zhǔn)點(diǎn)式的大量更新命中。這可以通過(guò)針對(duì)用戶期望同時(shí)進(jìn)行所有的更新來(lái)平衡。此外，當(dāng)服務(wù)器使用上述的跳過(guò)小時(shí)或跳過(guò)天的特征時(shí)，客戶端不應(yīng)該在延期時(shí)段過(guò)去后馬上取更新。代替地，客戶端應(yīng)該在取內(nèi)容前等待至多達(dá)15分鐘的隨機(jī)時(shí)間間隔。為了在這方面協(xié)助同步引擎，訂閱源進(jìn)度表模塊302可以為每個(gè)訂閱源維持一個(gè)狀態(tài)，諸如新鮮和陳舊。"新鮮"的狀態(tài)意味著基于發(fā)布人的進(jìn)步表，訂閱源是新鮮的。"陳舊"狀態(tài)意味著發(fā)布人的進(jìn)度表指示了更新，但同步引擎還沒(méi)有完成更新。對(duì)最新內(nèi)容感興趣的客戶端可以請(qǐng)求立即更新，并在可用時(shí)被通知。如果設(shè)置了該期望，那么同步引擎可以在更新內(nèi)容時(shí)實(shí)現(xiàn)任意的延時(shí)，而非嚴(yán)格地根據(jù)進(jìn)度表而損害用戶和服務(wù)器。有關(guān)如何下載訂閱源，考慮如下情況。在一個(gè)實(shí)施例中，同步引擎可以使用任務(wù)調(diào)度器來(lái)在預(yù)定時(shí)刻啟動(dòng)同步引擎程序。在同步引擎完成后，它用它應(yīng)該再次啟動(dòng)同步引擎的下一次時(shí)間(即NextSyncEngineLaunchTime(下一次同步引擎啟動(dòng)時(shí)間))來(lái)更新任務(wù)進(jìn)度表。當(dāng)同步引擎啟動(dòng)時(shí)，它使得所有其NextUpdateTime(下一次更新時(shí)間)小于或等于currentTime(當(dāng)前時(shí)間)的"掛起"訂閱源列隊(duì)等候，并接著如下處理它們。對(duì)于每個(gè)訂閱源，跟蹤以下特性LastUpdateTime(上次更新時(shí)間)、NextUpdateTime、(用分鐘數(shù)指定的)Interval(間隔)和LastErrorlnterval(上次錯(cuò)誤間隔)。在成功地同步了訂閱源結(jié)束時(shí)，訂閱源的LastUpdateTime被設(shè)置成當(dāng)前時(shí)間，而NextUpdateTime被設(shè)置成LastUpdateTime加上時(shí)間間隔加上隨機(jī)值(時(shí)間間隔的1/10)。具體如下LastUpdateTime=currentTimeNextUpdateTime=currentTime+Interval+Random(Interval*0.1)ErrorInterval=0Random(argument)(隨機(jī)(自變量))被定義成1及其argument(自變量)之間的正值。例如Random(lO)返回0到10之間的浮動(dòng)值。如果因?yàn)橐韵略蛑?，同步訂閱源失敗HTTP4xxresponsecode(響應(yīng)代碼)，.HTTP5xxresponsecode(卩向應(yīng)代碼)，'Winsock/networkerror(網(wǎng)絡(luò)出辛昔)；or(或者)HTTP200,butresponsebodyhasaparsingerror(notarecognizedfeedformat)(響應(yīng)實(shí)體有解析錯(cuò)誤(不是公認(rèn)的訂閱源格式))那么如下應(yīng)用指數(shù)補(bǔ)償算法LastUpdateTime=<imchanged(不變)>Error工ntei:val=min(max(Error工nterval*2,lmin),Interval)NextUpdateTime=currentTime+Error工nterval+Random(Errorlnterval*0.1)在完成了所有"掛起"訂閱源的同步后，同步引擎判定是否有任一訂閱源超過(guò)了其NextUpdateTime(NextUpdateTime<=currentTime)。如果有，那么就如同剛啟動(dòng)同步引擎一樣來(lái)列隊(duì)并處理那些"掛起"訂閱源。如果有未完成的"掛起"訂閱源，則同步引擎判定是否有任何其NextUpdateTime在當(dāng)前時(shí)間的2分鐘之內(nèi)(currentTime+2min>=NextUpdateTime)的"即將同步"訂閱源。如果有任何"即將同步"訂閱源，那么同步引擎進(jìn)程繼續(xù)運(yùn)行，并且將定時(shí)器設(shè)置為在NextUpdateTime時(shí)"醒來(lái)"，并處理"掛起"訂閱源。如果沒(méi)有"即將同步"訂閱源，那么NextSyncEngineLaunch被設(shè)置成具有最早NextUpdateTime的訂閱源的NextUpdateTime。接著任務(wù)調(diào)度器被設(shè)置成NextSyncEngineLaunchTime，并且同步引擎進(jìn)程結(jié)束。依照一個(gè)實(shí)施例，如果在隊(duì)列中有若干個(gè)"掛起"訂閱源，那么同步引擎可以并行地同步多個(gè)訂閱源。然而，并行同步的數(shù)目應(yīng)該是有限的，在某個(gè)時(shí)間段內(nèi)執(zhí)行多少個(gè)同步也應(yīng)該是有限的，以便避免占盡網(wǎng)絡(luò)帶寬和處理器利用率。依照一個(gè)實(shí)施例，訂閱源同步的形成經(jīng)由令牌存儲(chǔ)段(token-bucket)提供。在概念上，令牌存儲(chǔ)段如下工作。*每l/r秒將令牌加入到存儲(chǔ)段中。*存儲(chǔ)段可以最多保存b個(gè)令牌；如果當(dāng)令牌達(dá)到時(shí)存儲(chǔ)段是滿的，就將其丟棄；當(dāng)一訂閱源需要被同步時(shí)，從存儲(chǔ)段中移出令牌并將該訂閱源同步。*如果沒(méi)有令牌可用，那么訂閱源就待在隊(duì)列中，并且等待直至有令牌變得可用。這種方法允許多達(dá)b個(gè)訂閱源的突發(fā)訂閱源同步。不過(guò)，經(jīng)過(guò)長(zhǎng)時(shí)間運(yùn)行，同步被限制為恒速r。在實(shí)現(xiàn)示例中，同步引擎為b和r使用以下值b=4ir=2。訂閱源內(nèi)容下載模塊——304依照一個(gè)實(shí)施例，訂閱源內(nèi)容下載模塊304處理下載訂閱源并將新的訂閱源項(xiàng)目與現(xiàn)有訂閱源數(shù)據(jù)合并的進(jìn)程。作為如何實(shí)現(xiàn)訂閱源內(nèi)容下載模塊的示例，考慮如下情況。在適當(dāng)?shù)臅r(shí)候，同步引擎經(jīng)由訂閱源內(nèi)容下載模塊連接到服務(wù)器并下載適當(dāng)?shù)膬?nèi)容。依照一個(gè)實(shí)施例，平臺(tái)被配置成支持不同的協(xié)議以下載內(nèi)容。例如，同步引擎可以支持經(jīng)HTTP下載訂閱源文檔。此外，同步引擎可以支持加密的HTTPURL(例如SSL、https等)。同樣地，同步引擎也可以支持使用HTTPgzip支持的壓縮，并支持從通用命名標(biāo)準(zhǔn)(UNC)共享的訂閱源下載。此外，同步引擎經(jīng)由訂閱源內(nèi)容下載模塊可以支持各種類型的身份驗(yàn)證。例如，同步引擎可以存儲(chǔ)每個(gè)訂閱源的用戶名/密碼，并可以使用用于HTTP基本身份驗(yàn)證的該用戶名/密碼來(lái)檢索訂閱源文檔。有關(guān)更新訂閱源，考慮如下情況。為了判定訂閱源是否有新的內(nèi)容，同步引擎為每個(gè)訂閱源保存如下信息片段*由對(duì)HTTP響應(yīng)的上次修改的報(bào)頭所報(bào)告的上次更新訂閱源的時(shí)間；*上次HTTP響應(yīng)中Etag報(bào)頭的值；以及*訂閱源最近pubDate的值(即訂閱源級(jí)發(fā)布日期和時(shí)間)。如果站點(diǎn)支持Etag或上次修改，那么同步引擎可以使用這些來(lái)檢查是否有新內(nèi)容。站點(diǎn)可以使用HTTP響應(yīng)代碼304來(lái)響應(yīng)，以指示沒(méi)有新內(nèi)容。否則，就下載內(nèi)容。例如，如果站點(diǎn)支持RFC3229-for-feeds(關(guān)于訂閱源的RFC3229)，那么站點(diǎn)可以基于客戶端傳遞的Etag僅返回新的內(nèi)容。不管使用那種方式，客戶端接著將新內(nèi)容與已存儲(chǔ)的內(nèi)容合并。作為如何能夠下載訂閱源內(nèi)容的一個(gè)實(shí)施示例更為詳細(xì)的描述，考慮如下情況。為了判定特定的站點(diǎn)是否已被改變，同步引擎可以提交帶有如下信息的請(qǐng)求*如果客戶端有保存的Etag，則是//-Wo"e-M^c/z0^無(wú)^5"^9報(bào)頭；O帶有以下值的報(bào)頭A-IM:訂閱源、gzip(用于RFC3229-for-feeds);*如果客戶端有保存的上次修改的值，則是//-^^//^-&>^C^,存參改J報(bào)頭。如果服務(wù)器用HTTP響應(yīng)代碼304響應(yīng)，則內(nèi)容尚未被改變，且進(jìn)程在這里結(jié)束。如果服務(wù)器用內(nèi)容(即HTTP代碼200或206)響應(yīng)，則將下載的內(nèi)容與本地內(nèi)容合并(注意代碼206指服務(wù)器支持RFC3229-for-feeds，而所下載的內(nèi)容僅是新內(nèi)容)。如果內(nèi)容可用且如果同步引擎有已存儲(chǔ)的pubDate，并且下載的訂閱源文檔包含信道級(jí)別pubDate元素，那么就比較這兩個(gè)日期。如果本地pubDate與下載的pubDate相同，那么內(nèi)容還沒(méi)有被更新。于是可以丟棄下載的訂閱源文檔。如果同步引擎每次處理一個(gè)項(xiàng)目，那么就將每個(gè)項(xiàng)目的pubDate與同步引擎存儲(chǔ)(如果有的話)的pubDate作比較，并丟棄較老的項(xiàng)目。接著將每個(gè)項(xiàng)目與存儲(chǔ)中的項(xiàng)目作比較。比較應(yīng)該使用GUID元素(如果存在的話)或者link(鏈接)元素(如果不存在GUID)。如果發(fā)現(xiàn)匹配，那么新項(xiàng)目的內(nèi)容就替換老項(xiàng)目的內(nèi)容(如果兩者都有pubDate,那么就用它來(lái)判定哪個(gè)更加新，否則最近下載的是新的)。如果沒(méi)有發(fā)現(xiàn)匹配，那么新的項(xiàng)目比存儲(chǔ)的訂閱源內(nèi)容被先等待處理(維持"最近在上"的語(yǔ)義)。如果在本地訂閱源中增加或更新了任何項(xiàng)目，那么就認(rèn)為訂閱源是經(jīng)更新的，并且通知RSS平臺(tái)的客戶端。對(duì)于出錯(cuò)情況，考慮如下各項(xiàng)。如果服務(wù)器用代碼500或大多數(shù)400錯(cuò)誤響應(yīng)，那么就重置同步進(jìn)度表并且服務(wù)器稍后再試。然而HTTP錯(cuò)誤410應(yīng)該被當(dāng)作將更新進(jìn)度表重置為"不再更新"的指示。隨后應(yīng)該是HTTP級(jí)別的重定向，但不應(yīng)對(duì)客戶端配置作出改變(存在幾種偶然地作出重定向的不合理情況)。如果服務(wù)器用XML重定向來(lái)響應(yīng)，那么應(yīng)該重定向訂閱源，并且所存儲(chǔ)的指向訂閱源的URL應(yīng)該被自動(dòng)更新。這是客戶端自動(dòng)更新訂閱源URL的唯一情況。對(duì)于下載訂閱源，當(dāng)用戶參與其他任務(wù)時(shí)，下載不應(yīng)該中斷機(jī)器的普通使用(例如，帶寬或CPU)。此外，在依賴于內(nèi)容的交互式應(yīng)用程序中，用戶應(yīng)該能夠盡可能快地獲取內(nèi)容。附件下載模塊一一306依照一個(gè)實(shí)施例，附件下載模塊306負(fù)責(zé)為訂閱源下載附件文件并應(yīng)用適當(dāng)?shù)陌踩珔^(qū)。在下載訂閱源內(nèi)容時(shí)，也下載附件?？梢杂脦追N不同的方式處理下載附件。首先，認(rèn)為基本附件是RSS2.0風(fēng)格的附件。對(duì)于基本附件，同步引擎會(huì)經(jīng)由附件下載模塊306為附件鏈接自動(dòng)解析下載的訂閱源。同步引擎被配置成支持多個(gè)基本附件。使用附件鏈接，附件下載模塊于是可以下載附件。在至少某些實(shí)施例中，對(duì)于任何新的訂閱源，默認(rèn)的動(dòng)作是不下載基本附件。使用暴露上述對(duì)象模型的API,客戶端可以作出諸如基于每個(gè)訂閱源將其行為改變?yōu)槔缈偸窍螺d附件或強(qiáng)制下載特定訂閱源中特定項(xiàng)目的特定附件等的動(dòng)作?？梢酝ㄟ^(guò)使用上述通用格式提供增強(qiáng)的附件處理。具體地，至少在一個(gè)實(shí)施例中，通用格式為附件定義額外的功能。具體地，通用格式允許對(duì)特定內(nèi)容的多種表示。這包括例如預(yù)覽內(nèi)容和默認(rèn)內(nèi)容的標(biāo)準(zhǔn)定義以及指示是否應(yīng)該下載或流化附件的能力。此外，通用格式允許附件和內(nèi)容表示上的任意元數(shù)據(jù)。對(duì)于任何新的訂閱源，默認(rèn)動(dòng)作是下載任何附件的"預(yù)覽"版本，該"預(yù)覽"版本遵守例如每個(gè)項(xiàng)目10k的默認(rèn)尺寸限制。使用API，客戶端可以作出諸如基于每個(gè)訂閱源改變行為等的動(dòng)作。例如，可以將行為改變?yōu)榭偸窍螺d訂閱源中項(xiàng)目的"默認(rèn)"版本或總是下載具有特定值的元數(shù)據(jù)元素的任何特定版本。這可以使用為每個(gè)附件提供"下載這個(gè)？"邏輯的客戶端回叫信號(hào)來(lái)完成。此外，使用API，客戶端可以強(qiáng)制立即下載特定訂閱源中任意特定項(xiàng)目(或所有項(xiàng)目)的任何特定附件的任何特定表示。關(guān)于在附件下載過(guò)程中提供安全性，考慮以下情況。依照一個(gè)實(shí)施例，下載的附件使用WindowsXPSP2附件執(zhí)行服務(wù)(SP2AES)功能。這種功能可以提供基于文件類型和區(qū)的安全性。例如，擁有文件名和區(qū)信息(即附件來(lái)自哪里)，AES可以指示是否要阻止、允許或提示。對(duì)于區(qū)持久性而言，當(dāng)保存文件時(shí)，AES可以持續(xù)保存區(qū)信息，這樣當(dāng)隨后被打開(kāi)時(shí)，可以提示用戶。以下的表格描述了AES危險(xiǎn)級(jí)別/區(qū)到動(dòng)作的映射<table>tableseeoriginaldocumentpage16</column></row><table>在所示和所描述的實(shí)施例中，同步引擎將為它下載的每個(gè)附件調(diào)用一方法，例如::CheckPolicy?；陧憫?yīng)，同步引擎會(huì)進(jìn)行以下之一的操作*阻止不保存(在訂閱源文件中將其標(biāo)記為失敗)；*允許保存附件*提示保存，但是持續(xù)保存區(qū)信息。這意味著如果用戶雙擊該文件，他們會(huì)得到"運(yùn)行/不運(yùn)行"提示。依照一個(gè)實(shí)施例，同步引擎會(huì)首先將附件保存到盤上，并且不會(huì)將附件下載到存儲(chǔ)器中。保存到盤上觸發(fā)基于過(guò)濾器的反病毒應(yīng)用程序，并給予這些應(yīng)用程序隔離附件的機(jī)會(huì)(如果他們選擇)。存檔模塊——308依照一個(gè)實(shí)施例，存檔模塊308負(fù)責(zé)處理舊的訂閱源數(shù)據(jù)。默認(rèn)地，訂閱源最多保存200個(gè)項(xiàng)目。當(dāng)訂閱源超過(guò)指定最大值時(shí)，存檔模塊會(huì)刪除較老的訂閱源項(xiàng)目。然而卻不刪除相關(guān)聯(lián)的附件。訂閱源存儲(chǔ)器依照一個(gè)實(shí)施例，訂閱源存儲(chǔ)器112(圖1)保存兩種類型的信息——訂閱源列表114和訂閱源數(shù)據(jù)116。作為一個(gè)示例，考慮圖4。其中，訂閱源列表114被具體化為訂閱源列表的分層樹(shù)結(jié)構(gòu)400。訂閱源數(shù)據(jù)116包括與特定訂閱源相關(guān)聯(lián)的數(shù)據(jù)。在該示例中，基于每個(gè)訂閱源來(lái)排列訂閱源數(shù)據(jù)116以包括項(xiàng)目和附件的集合402。有許多種可以實(shí)現(xiàn)訂閱源存儲(chǔ)器的不同方式。在該特定實(shí)施例中，訂閱源存儲(chǔ)器包括文件系統(tǒng)的部分。這樣做的理由之一涉及簡(jiǎn)單性。即在該實(shí)施例中，訂閱源列表被簡(jiǎn)單地表示為其下可以有子目錄和文件的常規(guī)目錄。分層則被反映為常規(guī)文件系統(tǒng)分層。由此，諸如"新聞"和"網(wǎng)絡(luò)日志"等的每個(gè)文件夾本質(zhì)上是文件系統(tǒng)中帶有子目錄和文件的常規(guī)目錄。在該特定示例中，存在表示訂閱源訂閱的特別文件類型。僅作為示例，考慮這種類型的文件有以下格式"xyz.stg"。.stg文件存儲(chǔ)有關(guān)訂閱源的所有數(shù)據(jù)。由此，你會(huì)有一個(gè)訂閱源列表，諸如具體化為樹(shù)型結(jié)構(gòu)400的列表，且在每個(gè)訂閱源(或文件)中的是訂閱源數(shù)據(jù)。在所示和所描述的實(shí)施例中，使用結(jié)構(gòu)化存儲(chǔ)技術(shù)來(lái)實(shí)現(xiàn).stg文件。結(jié)構(gòu)化存儲(chǔ)技術(shù)是公知的，并且為本領(lǐng)域的技術(shù)人員所理解。但作為簡(jiǎn)要的背景，考慮以下情況。結(jié)構(gòu)化存儲(chǔ)通過(guò)將單個(gè)文件作為對(duì)象的結(jié)構(gòu)化集合(被稱為存儲(chǔ)和流)來(lái)處理，以在COM中提供文件和數(shù)據(jù)的持久性。結(jié)構(gòu)化存儲(chǔ)的目的是減少性能損失以及與在不同文件中存儲(chǔ)分開(kāi)的各對(duì)象部分的開(kāi)銷。結(jié)構(gòu)化存儲(chǔ)提供了一種解決方案，即通過(guò)定義如何經(jīng)由被稱為復(fù)合文件的標(biāo)準(zhǔn)實(shí)現(xiàn)而將單個(gè)文件實(shí)體作為兩種類型的對(duì)象(存儲(chǔ)和流)的結(jié)構(gòu)化集合來(lái)處理。這允許用戶如同復(fù)合文件是單個(gè)文件而非分開(kāi)對(duì)象的嵌套分層一樣來(lái)與之交互并管理它。本領(lǐng)域的技術(shù)人員會(huì)理解，存儲(chǔ)對(duì)象和流對(duì)象用作文件中的文件系統(tǒng)。結(jié)構(gòu)化存儲(chǔ)通過(guò)消除每當(dāng)新的對(duì)象被增加到復(fù)合文件中或現(xiàn)有對(duì)象尺寸增加時(shí)要將文件完全地重寫到存儲(chǔ)中的需求來(lái)解決性能問(wèn)題。新的數(shù)據(jù)被寫入到永久性存儲(chǔ)的下一個(gè)可用位置，且存儲(chǔ)對(duì)象更新它維持的指針表格來(lái)跟蹤其存儲(chǔ)對(duì)象和流對(duì)象的位置。因此，在所示和所描述的實(shí)施例中，使用結(jié)構(gòu)化存儲(chǔ)技術(shù)來(lái)實(shí)現(xiàn).Stg文件，且訂閱源存儲(chǔ)器頂上的API允許訪問(wèn)不同的流和存儲(chǔ)。在該特定示例中，將每個(gè)RSS項(xiàng)目寫入到一個(gè)流中。此外，報(bào)頭流包含與特定訂閱源相關(guān)聯(lián)的信息，諸如標(biāo)題、訂閱、訂閱源URL等。此外，另一流存儲(chǔ)索引類型的元數(shù)據(jù)，從而允許出于包括快速將某物標(biāo)記為可讀/不可讀、刪除項(xiàng)目等目的而快速并有效地訪問(wèn)文件中的內(nèi)容。文件系統(tǒng)——附件在所示和所描述的實(shí)施例中，附件不是以結(jié)構(gòu)化存儲(chǔ)方式或作為訂閱源數(shù)據(jù)的一部分來(lái)存儲(chǔ)，如圖l所示。相反地，附件被識(shí)別為其他應(yīng)用程序和用戶可能希望訪問(wèn)或操作的項(xiàng)目，諸如一個(gè)或一些圖片。由此，在所示和所描述的實(shí)施例中，將附件寫入到用戶的特定簡(jiǎn)檔中。但要維持附件和所關(guān)聯(lián)的訂閱源項(xiàng)目之間的鏈接。作為一個(gè)示例，考慮圖5。一旦用戶開(kāi)始訂閱一訂閱源，那么就將訂閱源內(nèi)容本地地存儲(chǔ)在用戶的簡(jiǎn)檔下，在ApplicationData(應(yīng)用程序數(shù)據(jù))或已知文件夾"feeds"中。訂閱源列表和訂閱源被存儲(chǔ)在ApplicationData中，以便能夠更好地控制訂閱源列表的格式和訂閱源。API被暴露(如下文將描述的)使得應(yīng)用程序能夠訪問(wèn)和管理訂閱源。訂閱源列表是用戶訂閱的一組訂閱源。在該示例中，包括訂閱源列表的文件位于C:\Users\<Username〉\AppData\Roaming\Microsoft\RSS\文件包含訂閱源的屬性以及項(xiàng)目和附件屬性(指向與項(xiàng)目相關(guān)聯(lián)的文件的URL)。例如，訂閱源"NYT"的文件位于C:\Users\<Username〉\AppData\Roaming\Microsoft\RSS\NYT.stg在該示例中，由訂閱源對(duì)附件進(jìn)行分組，并且將其存儲(chǔ)在已知文件夾(Knownfolder)"feeds"中。這允許用戶和其他應(yīng)用程序方便地訪問(wèn)和使用已下載的文件。例如，用戶訂閱NPR訂閱源并希望確保他們的媒體播放器應(yīng)用程序能夠自動(dòng)地添加那些文件。將這做成一個(gè)已知文件夾能讓用戶從媒體播放器瀏覽它并將其設(shè)置為監(jiān)控的文件夾。附件具有訂閱源和貼子的適當(dāng)?shù)脑獢?shù)據(jù)，使得應(yīng)用程序可以訪問(wèn)相關(guān)聯(lián)的貼子和訂閱源。附件位于如下所示C:\Users\<Username>\Feeds\<Feedname〉\寫入用戶的硬盤的每個(gè)附件會(huì)具有包含有關(guān)該附件的元數(shù)據(jù)的次級(jí)流(例如NTFS流)。作為示例而非限制，元數(shù)據(jù)可以包括附件所來(lái)自的訂閱源、作者、指向訂閱源項(xiàng)目的鏈接、描述、標(biāo)題、發(fā)布日期和下載日期以及其他合適的元數(shù)據(jù)。發(fā)布引擎/貼子隊(duì)列通常當(dāng)人們寫常規(guī)的網(wǎng)絡(luò)日志貼子時(shí)，本質(zhì)上正在寫入的是RSS項(xiàng)目。這個(gè)RSS項(xiàng)目一般被發(fā)送到某種類型的服務(wù)器，該服務(wù)器維持帳號(hào)信息、網(wǎng)絡(luò)日志的位置等。在這種情況下，發(fā)布引擎110(圖1)被配置用以使得應(yīng)用程序能夠作出張貼或發(fā)布內(nèi)容，而同時(shí)從應(yīng)用程序提取用于與服務(wù)器通信的通信協(xié)議。因此，應(yīng)用程序僅需要提供要張貼的數(shù)據(jù)或內(nèi)容，而發(fā)布引擎會(huì)處理格式化以及將內(nèi)容傳遞給適當(dāng)?shù)姆?wù)器的剩余任務(wù)。由于存在可使用的若干種不同的協(xié)議，因而從應(yīng)用程序提取協(xié)議提供了在使得許多不同類型的應(yīng)用程序能夠利用發(fā)布功能的范圍內(nèi)提供了很大的靈活性。在所示和所描述的實(shí)施例中，發(fā)布引擎功能被實(shí)現(xiàn)為允許應(yīng)用程序張貼網(wǎng)絡(luò)日志而無(wú)需知道用于與服務(wù)器通信的協(xié)議的API。因此，在該示例中，API具有一種創(chuàng)建新的貼子的方法，當(dāng)調(diào)用該方法時(shí)就創(chuàng)建RSSItem(RSS項(xiàng)目)對(duì)象。該RSSItem對(duì)象則具有一種張貼方法，當(dāng)調(diào)用該方法時(shí)，將內(nèi)容(在該情況下為網(wǎng)絡(luò)日志)存儲(chǔ)在臨時(shí)存儲(chǔ)器，即貼子隊(duì)列122(圖1)中。內(nèi)容被存儲(chǔ)在臨時(shí)存儲(chǔ)器中是因?yàn)樵趧?chuàng)建網(wǎng)絡(luò)日志時(shí)用戶可能不在線。接著，當(dāng)用戶作出在線連接時(shí)，發(fā)布引擎110連接到適當(dāng)?shù)姆?wù)器，并使用適于服務(wù)器的協(xié)議來(lái)將網(wǎng)絡(luò)日志上傳到服務(wù)器上。實(shí)現(xiàn)示例在以下的描述中，描述了一組示例性API，僅作為提供人們?nèi)绾螌?shí)現(xiàn)和結(jié)構(gòu)化API以實(shí)現(xiàn)上述功能的一個(gè)示例。應(yīng)該理解也可以使用其他API而不背離所作權(quán)利要求的主題的精神和范圍。所述API—般被具體化為駐留在某些類型的計(jì)算機(jī)可讀介質(zhì)上的計(jì)算機(jī)可讀指令和數(shù)據(jù)。以下描述的API可用于操作用戶訂閱的訂閱源組(系統(tǒng)訂閱源列表)和訂閱源的屬性。此外，訂閱源數(shù)據(jù)API(即項(xiàng)目和附件)提供對(duì)存儲(chǔ)在訂閱源存儲(chǔ)器中的訂閱源的訪問(wèn)以及對(duì)訂閱源的自主下載。使用訂閱源API，諸如web瀏覽器、媒體播放器、數(shù)字圖像庫(kù)應(yīng)用程序等應(yīng)用程序隨后能夠暴露它們經(jīng)歷內(nèi)的訂閱源數(shù)據(jù)。在要描述的示例中，API被實(shí)現(xiàn)為COM雙重接口，使得API可用于腳本語(yǔ)言、管理的代碼以及原始Win32(C十+)代碼。圖6根據(jù)一個(gè)實(shí)施例示出了頂層對(duì)象或接口Ifeeds(接口訂閱源)以及IFeedFolder(接口訂閱源文件夾)對(duì)象或接口以及它們相關(guān)聯(lián)的屬性、方法和事件。在該示例中，IFeeds具有一個(gè)屬性--作為IFeedFolder的subscriptions(訂閱)。它是所有訂閱的根文件夾。對(duì)于根對(duì)象存在多種方法，諸如DeleteFeed()、DeleteFeedByGuid()、DeleteFolder()等。本示例中所感興趣的是GetFeedByGuid()方法。該方法可以由應(yīng)用程序調(diào)用以通過(guò)例如訂閱源的GUID來(lái)訪問(wèn)特定的訂閱源。因此，應(yīng)用程序無(wú)需知道訂閱源的分層排序。相反地，應(yīng)用程序可以使用訂閱源的GUID來(lái)使得平臺(tái)能夠取該訂閱源。此外，ExistFeed()方法按名稱檢查訂閱源的存在。而ExistFee犯yGuid()則按GUID檢查訂閱源的存在。GetFeed()方法按名稱或按GUID來(lái)獲取訂閱源。IsSubscribed()方法能讓應(yīng)用程序或調(diào)用程序確定特定的訂閱源是否被訂閱。此外，IFeeds對(duì)象也具有SubscriptionsNotifications(訂閱通知)事件，它允許登記系統(tǒng)訂閱源列表上改變的通知。如上所述，訂閱的類型是IFeedFolder。IFeedFolder對(duì)象或接口本質(zhì)上提供目錄，并具有相似類型的屬性，諸如Name(名稱)、Parent(父代)、Path(路徑)等。此外，IFeedFolder對(duì)象具有類型為IFeed的訂閱源屬性和類型為IFeedFolder的Subfolders(子文件夾)屬性。Subfolders屬性屬于即時(shí)文件夾(例如是導(dǎo)出分層結(jié)構(gòu)的文件夾)下的文件夾集合，而Feeds屬性屬于特定文件夾中的實(shí)際訂閱源。此外，IFeedFolder具有LastWriteTime(上次寫入時(shí)間)屬性，它指示上次將任何事寫入到文件夾中的時(shí)間。該屬性對(duì)于可能暫時(shí)還沒(méi)有運(yùn)行但是也需要查看訂閱源平臺(tái)并確定其狀態(tài)使得(如果需要)它可以同步的應(yīng)用程序有用。存在有關(guān)IFeedFolder的多種方法，其中一些屬于創(chuàng)建訂閱源(創(chuàng)建系統(tǒng)不具有的訂閱源并將其增加到特定文件夾中)、創(chuàng)建子文件夾、刪除文件夾或子文件夾等。圖7根據(jù)一個(gè)實(shí)施例示出了額外對(duì)象及其相關(guān)聯(lián)的方法。具體地示出了IFeed、Item禾口Ienclosure對(duì)象。首先從IFeed對(duì)象開(kāi)始，考慮如下情況。如本領(lǐng)域的技術(shù)人員所理解的，許多與該對(duì)象相關(guān)聯(lián)的屬性來(lái)自RSS訂閱源自身，例如Title(標(biāo)題)、Url、Webmaster(Web管理員)、SkipHours(跳過(guò)小時(shí))、SkipDays(跳過(guò)天數(shù))、ManagingEditor(管理編輯器)、Homepage(主頁(yè))、ImageURL(圖像URL)等。此外，有另一組感興趣的屬性，即具有所有作為訂閱源部分的全部項(xiàng)目的集合的Items屬性以及提供所有附件所寫入的實(shí)際目錄的LocalEnclosurePath(本地附件路徑)屬性。由此，對(duì)于應(yīng)用程序，后一種屬性使得應(yīng)用程序能夠非常方便地訪問(wèn)附件。此外，該對(duì)象支持一小組方法，諸如Delete()和Download()等用于管理特定訂閱源的方法。另外，該對(duì)象支持方法XML()，它以通用格式返回訂閱源的XML。XML數(shù)據(jù)可以用于諸如創(chuàng)建訂閱源的報(bào)紙觀點(diǎn)等事情。Clone()返回未訂閱的訂閱源的副本。前進(jìn)到Item對(duì)象，該對(duì)象具有一組表示常規(guī)RSS元素的屬性，所述RSS元素例如Description(描述)、Url、Title(標(biāo)題)、Author(作者)等。此外，有指回到相關(guān)聯(lián)的實(shí)際訂閱源的Parent(父代)屬性，以及使得應(yīng)用程序能夠操作Id而非必須重復(fù)所有的項(xiàng)目的Id屬性。此外，有Enclosures(附件)屬性，它是類型為IEndosure的項(xiàng)目的附件的集合。另外，IsRead(讀了嗎)屬性使得應(yīng)用程序能夠指示是否讀過(guò)特定項(xiàng)目。前進(jìn)到Enclosure對(duì)象，考慮以下情況。該對(duì)象具有包括Type(類型)屬性(例如mp3)和描述特定附件的長(zhǎng)度的Length(長(zhǎng)度)屬性的屬性。對(duì)于特定的附件也有LocalAbsolutePath(本地絕對(duì)路徑)。Download()方法允許應(yīng)用程序下載和使用個(gè)別的附件。總結(jié)上述web內(nèi)容聚合平臺(tái)可用于管理、組織從因特網(wǎng)獲取的內(nèi)容，并使之可用于消耗。平臺(tái)可以獲取和組織web內(nèi)容，并使這樣的內(nèi)容可由許多不同類型的應(yīng)用程序用于消耗。這些應(yīng)用程序可以必須理解特定的聚合格式，也可以不理解。應(yīng)用程序編程接口(API)暴露對(duì)象模型，以允許應(yīng)用程序和用戶方便地完成諸如創(chuàng)建、讀取、更新、刪除訂閱源等許多不同任務(wù)。此外，平臺(tái)可以提取特定的訂閱源格式，以提供促進(jìn)進(jìn)入平臺(tái)的訂閱源數(shù)據(jù)的可用性的通用格式。另外，平臺(tái)以可使得附件對(duì)知道聚合的應(yīng)用程序和不知道聚合的應(yīng)用程序都可消耗的方式來(lái)處理和管理經(jīng)由web訂閱源接收到的附件。雖然使用特定于結(jié)構(gòu)化特征和/或方法步驟的語(yǔ)言描述了本發(fā)明，但是應(yīng)該理解在所附權(quán)利要求書(shū)中定義的本發(fā)明不是必須限于所描述的特定特征和步驟。相反地，所公開(kāi)的特定特征和步驟是作為實(shí)現(xiàn)所作權(quán)利要求的本發(fā)明的優(yōu)選形式。權(quán)利要求1.一種系統(tǒng)，包括一種或多種計(jì)算機(jī)可讀介質(zhì)；在所述介質(zhì)上用以實(shí)現(xiàn)內(nèi)容聚合平臺(tái)的計(jì)算機(jī)可讀指令，所述內(nèi)容聚合平臺(tái)包括被配置用以從源中獲取內(nèi)容并使得所述內(nèi)容對(duì)知道聚合的應(yīng)用程序和不知道聚合的應(yīng)用程序都可用的訂閱源同步引擎；以及被配置用以存儲(chǔ)訂閱源列表和訂閱源數(shù)據(jù)的訂閱源存儲(chǔ)器。2.如權(quán)利要求l所述的系統(tǒng)，其特征在于，所述訂閱源同步引擎被配置用以將不同格式的內(nèi)容轉(zhuǎn)換成通用格式。3.如權(quán)利要求l所述的系統(tǒng)，其特征在于，所述訂閱源同步引擎被配置用以支持多種不同類型的進(jìn)度表，所述進(jìn)度表的至少一類包括定義了最小更新時(shí)間的最小調(diào)度表，而所述最小更新時(shí)間則定義了各更新之間的時(shí)間段。4.如權(quán)利要求l所述的系統(tǒng)，其特征在于，所述訂閱源同步引擎被配置用以下載訂閱源數(shù)據(jù)并更新在前下載的訂閱源數(shù)據(jù)。5.如權(quán)利要求l所述的系統(tǒng)，其特征在于，所述訂閱源同步引擎被配置用以下載附件并將這些附件提供給文件系統(tǒng)，其中所述附件能夠被不知道聚合的應(yīng)用程序訪問(wèn)。6.如權(quán)利要求5所述的系統(tǒng)，其特征在于，所述平臺(tái)被配置用以將附件寫入用戶簡(jiǎn)檔。7.如權(quán)利要求6所述的系統(tǒng)，其特征在于，所述平臺(tái)被配置用以維護(hù)附件和關(guān)聯(lián)訂閱源項(xiàng)目之間的鏈接。8.如權(quán)利要求1所述的系統(tǒng)，其特征在于，所述訂閱源存儲(chǔ)器被實(shí)現(xiàn)作為文件系統(tǒng)的部分。9.如權(quán)利要求8所述的系統(tǒng)，其特征在于，所述訂閱源列表被表示為能夠具有子目錄的目錄。10.如權(quán)利要求8所述的系統(tǒng)，其特征在于，所述訂閱源列表和訂閱源數(shù)據(jù)在所述文件系統(tǒng)內(nèi)使用結(jié)構(gòu)化存儲(chǔ)技術(shù)管理。11.如權(quán)利要求1所述的系統(tǒng)，其特征在于，所述訂閱源同步引擎被配置使得用戶能夠以從所述用戶應(yīng)用程序和發(fā)布位置之間提取通信協(xié)議的方式來(lái)發(fā)布內(nèi)容。12.如權(quán)利要求1所述的系統(tǒng)，其特征在于，所述聚合平臺(tái)被配置用以進(jìn)行訂閱源同步。13.如權(quán)利要求l所述的系統(tǒng)，其特征在于，所述內(nèi)容聚合平臺(tái)包括RSS平臺(tái)14.一種系統(tǒng)，包括包含一組應(yīng)用程序接口的一種或多種計(jì)算機(jī)可讀介質(zhì)，包括充當(dāng)用于訂閱的根文件夾并且具有屬于訂閱源的一種或多種方法的第一接口；充當(dāng)用于訂閱源的文件夾的第二接口，其中所述第二接口具有訂閱源屬性和子文件夾屬性以及屬于文件夾的一種或多種方法；包括與單個(gè)訂閱源相關(guān)聯(lián)的屬性以及屬于單個(gè)訂閱源的一種或多種方法的第三接口；包括與單個(gè)項(xiàng)目相關(guān)聯(lián)的屬性以及屬于單個(gè)項(xiàng)目的至少一種方法的第四接口；包括與單個(gè)附件相關(guān)聯(lián)的屬性以及與單個(gè)附件相關(guān)聯(lián)的一種或多種方法的第五接口，其中至少一種方法允許附件被應(yīng)用程序下載。15.如權(quán)利要求14所述的系統(tǒng)，其特征在于，所述第一接口具有一種在不要求對(duì)訂閱源的訂閱的情況下下載訂閱源的方法。16.如權(quán)利要求14所述的系統(tǒng)，其特征在于，所述第一接口包括允許應(yīng)用程序注冊(cè)屬于系統(tǒng)訂閱源列表的通知的通知事件。17.如權(quán)利要求14所述的系統(tǒng)，其特征在于，所述第二接口包括指示上次數(shù)據(jù)寫入關(guān)聯(lián)文件夾的時(shí)間的屬性。18.如權(quán)利要求14所述的系統(tǒng)，其特征在于，所述第三接口包括作為與一特定訂閱源相關(guān)聯(lián)的項(xiàng)目集合的項(xiàng)目屬性以及提供單個(gè)附件被寫入的目錄的本地附件路徑屬性。19.如權(quán)利要求14所述的系統(tǒng)，其特征在于，所述第三接口包括一種把訂閱源的XML返回給調(diào)用程序的方法。20.如權(quán)利要求14所述的系統(tǒng)，其特征在于，所述第四接口包括指向關(guān)聯(lián)訂閱源的父代屬性以及與項(xiàng)目的附件相關(guān)聯(lián)的附件屬性。全文摘要諸如web內(nèi)容聚合平臺(tái)的內(nèi)容聚合平臺(tái)管理、組織從因特網(wǎng)獲取的內(nèi)容，并使之可用于消耗。在至少某些實(shí)施例中，平臺(tái)可以獲取和組織web內(nèi)容，并使得這種內(nèi)容可由許多不同類型的應(yīng)用程序用于消耗。這些應(yīng)用程序可以必須理解特定的聚合格式，也可以不理解。應(yīng)用程序編程接口(API)暴露對(duì)象模型，以允許應(yīng)用程序和用戶方便地完成諸如創(chuàng)建、讀取、更新、刪除訂閱源等許多不同任務(wù)。文檔編號(hào)G06F9/45GK101288048SQ200680021415公開(kāi)日2008年10月15日申請(qǐng)日期2006年6月14日優(yōu)先權(quán)日2005年6月21日發(fā)明者E·J·帕瑞茨申請(qǐng)人:微軟公司