Dav*_*ton 8 xml rss filesize feed
我正在为网站实现RSS提要,但我不了解有关提要的XML文件的格式/大小/内容的某些信息.
我正在使用过去的数据初始化网站,这些数据可以追溯到1999年(之前没有任何订阅源),每年只会添加几百个项目.
是否有一些归档协议,或者我可以保留一个文件并继续追加它？我认为那将是低效的,因为聚合器必须下载整个事物(我假设).
那么,通常的习惯是什么？限制在上个月？目前900多个项目的文件是1.5MB,我希望1年的价值大约是或者更小的1/10.
有关使用什么原则以及如何实现它的任何指示？我正在使用PHP,但我的数据很复杂,我编写了自己的脚本来编写文件(并且验证得很好),所以我不能使用固定解决方案 - 我需要了解自己要实现什么脚本.
联合供稿的大多数消费者都期望供稿将包含相对较新的内容,之前发布的内容会从供稿中"掉落".您在Feed中维护的内容通常取决于您要发布的内容类型,但随着Feed大小的增加,它会影响Feed客户端检索和解析您的信息的能力.
如果您确实要发布不断添加但尚未删除内容项的历史Feed,则可能需要考虑以下选项(根据您的使用者的需求):
只有当您知道将要使用Feed的Feed客户端类型时,选项1才是合理的方法,因为并非所有Feed客户端都支持分页.
选项2是面向公众的网站上最常见的选项,因为大多数浏览器和客户端都支持自动发现,您可以同时提供完整的历史源和较小的更新内容源(或者以对您有意义的方式提供段)内容).
选项3可能允许您提供前两个选项的优势,此外,您还可以提供多种Feed格式和丰富的内容过滤功能.这是一种非常强大的公开Feed内容的方式,但如果您的消费者表示希望定制他们希望使用的Feed内容,通常只值得努力.
虽然大多数富源订阅源客户端将异步检索订阅源内容,但是当您的订阅源大小增加时,对您的订阅源发出同步(并且可能频繁)请求的客户端可能会遇到超时问题.
无论您采取何种方向,请考虑在您的Feed上实施条件GET ; 并了解您的联合内容的潜在消费者,以便选择最适合的策略.当您考虑要提供哪种联合供稿格式时,请参阅此答案.