On 19/07/2005, at 1:48 AM, Stefan Eissing wrote:
Let's say CNN goes stateful, how would a client handle a history
which soon consists of thousands of entries. How would a server
best offer such a history to avoid clients retrieving it over and
over again. Probably nobody has a good idea on that one, or?
I have the feeling that clients will need to protect themselves
from servers with almost infinite histories. So a client will
probably offer a XX days into the past, max NN entries setting in
its UI. Maybe that is all that's needed.
Good question. I was thinking roughly along these lines in the
Security Considerations, but didn't want to lead people too much.
How about:
"In case feeds are served via HTTP, server implemenations SHOULD
offer ETag and Last-Modified headers on history documents (see RFC
2616 xxx). Clients SHOULD persist ETag and Last-Modified
information and use If-* headers to ease server load on history
synchronization."
Hmm. Maybe not SHOULDs, but some prose might lead people in the right
direction, perhaps an 'Implementer Notes' section?
--
Mark Nottingham http://www.mnot.net/
