RSS feed XML文件有多大？

Question

我正在實施一個網站的RSS提要，我不明白有關該提要的XML文件格式/大小/內容的某些事情。

我正在使用過去的數據初始化網站，這個數據可以追溯到1999年（現在沒有任何時間點的Feed），每年只會添加幾百個項目。

是否有一些存檔協議，或者我可以只保留一個文件並繼續附加到它？我認爲這將是低效的，因爲聚合器必須下載整個事情（我認爲）。

那麼，這通常是什麼習慣？限於上個月？目前擁有超過900個項目的文件是1.5MB，我預計1年的價值約爲大小的十分之一。

關於這個使用什麼原則以及如何實現它的任何指針？我使用的是PHP，但是我的數據足夠複雜了，我把自己的腳本編寫成文件（並且驗證得很好），所以我不能使用罐頭解決方案 - 我需要理解我自己的實現腳本。

Answer 1

大多數辛迪加飼料的消費者都期望飼料將包含相對較新的內容，並且以前發佈的內容會脫離飼料。 Feed中維護的內容通常基於您發佈的內容類型，但隨着Feed大小的增長，它可能會影響Feed客戶端檢索和解析信息的能力。

如果你真的想發佈一個不斷加入歷史飼料，但從來沒有的內容項刪除，你可能要考慮下列選項（根據你的消費者的需求）：

1. 實施Feed Paging and Archiving,per RFC 5005 Section 3，因爲當條目數量非常大，無限或不確定時，分頁提要可能很有用。客戶端可以通過供稿「頁面」，只需要訪問供稿條目的子集。
2. 從邏輯上將您的內容分成多個供稿，並將auto-discovery提供給您網站上的供稿。
3. 實現基於REST的服務接口，該服務接口允許消費者以Atom或RSS格式提要檢索和過濾您的內容，默認表示使用一些合理的默認值。

選項1是一種合理的方法只有當你知道飼料的客戶，將消耗你的飼料，因爲不是所有的飼料客戶端支持分頁的類型。

選項2是最常見的一種看到面向公衆的網站，因爲大多數瀏覽器和客戶端支持自動發現，並可以同時提供一個完整的歷史進和一個較小的更近的內容飼料（或段對您的內容有意義的方式）。

選項3潛在地允許您提供前兩個選項的好處，此外您還可以提供多種提要格式和豐富的內容過濾功能。這是揭示Feed內容的一種非常強大的方式，但通常只有當您的消費者表示希望剪裁他們希望消費的Feed內容時才付出努力。

儘管大多數豐富的訂閱源客戶端將異步檢索訂閱源內容，但隨着訂閱源大小增加，爲您的訂閱源提出同步（可能頻繁）請求的客戶端可能會遇到超時問題。

無論您採取什麼方向，都要考慮在您的Feed上實施Conditional GET;並瞭解您的聯合內容的潛在消費者，以便選擇最適合的策略。當您考慮要提供哪個聯合供稿格式時，請參閱this answer。

Answer 2

聚合器會重複下載文件，因此限制文件的大小非常重要。我會讓該Feed包含10個項目，或者在一週之前擁有最舊的項目，以獲取更多條目爲準，除非用GET參數覆蓋。當然，這會因您從客戶看到的實際使用情況以及Feed中的活動而有所不同。