何时刷新/替换 RSS 阅读器中的缓存
对于一个简单的 RSS 阅读器，我将查询结果存储在客户端（google gears）数据库中。
因此，myapp.php?query=xyz 存储在一个列中，结果 xml 存储在下一列中。
然后，当请求 myapp.php?query=xyz 时，我首先尝试从第二列中的缓存内容加载。
我需要弄清楚何时应该用服务器中的内容替换/刷新/覆盖缓存的内容。
我还需要弄清楚何时更新显示的数据。
在显示缓存内容之后，我是否应该在后台替换缓存，然后用户下次导航到该屏幕时会看到它？
我是否应该显示缓存的内容，然后在服务器返回新数据时替换“在他们眼前”的内容？
1）用新数据替换缓存2）更新显示数据的适当点是什么
任何帮助将不胜感激！
For a simple rss reader, I am storing the results of queries in a client side (google gears) database.
So, myapp.php?query=xyz is stored in one column, and the result xml is stored in the next column.
Then, when myapp.php?query=xyz is requested, I first attempt to load from the cached content in the second column.
I need to figure out when I should replace/refresh/overide that cached content with content from the server.
I also need to figure out when to update the displayed data.
Should I replace the cache in the background, after displaying the cached content, and then the user sees it next time they navigate to that screen?
Should I show the cached content and then replace the content "before their eyes" when the server returns new data?
What is the appropriate point to 1) replace the cache with new data 2) update the displayed data
Any help would be greatly appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
还将文件时间戳（或上次更改时间的时间戳）存储在数据库表的第三列中。当您检测到原始时间不同时，请获取新副本。
同样，您可以使用数据大小或适合您的内容的其他类型的检测机制来完成此操作。
除非需要实时数据，否则在网络上“眼前”大量替换信息是不寻常的。但由于其请求-响应无状态模型，网络应用程序可能不是实时数据的最佳选择。您肯定会使用更多的带宽来在他们眼前不断刷新它。
这取决于应用程序的要求。
Also store the file time stamp (or last time changed stamp) in a 3rd column of the database table. When you detect the origin time is different then grab a new copy.
Likewise you could do it with data size or some other kind of detection mechanism that fits your content.
It's unusual to replace info a lot 'before the eyes' on the web, unless there's a need for real-time data. But a web app might not be the best choice for real time data because of its request-response stateless model. You'll certainly use a lot more bandwidth to refresh it continually before their eyes.
It depends on the requirements of the app.