Mark Nottingham wrote:
Hi Graham,
Not demand; publishers aren't required to keep them.
It's also not about previous versions; it's about allowing them to catch up with entries (or changes to them) that they've missed.
IMO, this is one of the things that the Atom format can do to differentiate itself from RSS; it's really important. Please take a look before making a judgement.
I Have This Pattern.
1. I like it,m tho' I don't entirely buy the rationale - not sure if we're chartered for provisioning delivery SLAs.
2. My use case is non-standard, ie it's not blogging. It's for transmitting events of various sorts to a monitoring sink. Events are packed as atom 0.3 feeds. Transmission is done over xmpp.
3. The way it's 'solved' there is not by modelling a linked list with hyperlinks. Each feed representation is given a URI which can be rerequested or resent. They don't change over time. It's sufficiently different from the normal "sliding window" feed usage that I call these things "feed blocks" rather than "feeds".
4. I don't see that working out over HTTP, given that HTTP feeds entities are idiomatically a window onto a continuous stream of events.
5. Eventually, to programmatically retrieve stuff, there would be a feed of feed blocks. That feed would be a sliding window, but sliding at a much slower rate.
6. I agree with Walter's ob about archiving.
7. I think you move into rough terrain when you use 'feed' to imply a logical stream ("delayed list" in sicp speak), as well as whatever the current representation (window) you've been provided width.
8. //atom:head/atom:[EMAIL PROTECTED]'wholefeed'] strikes me as impractical, given sufficient time and monkeys with blogs.
Codifying it would be very useful, but given my use case and the protocol issues I won't push for this (Other than archiving, I haven't had time to think about the implications for http - there are feed/bandwidth ratios to consider, and they made my head hurt last time). I won't be surprised if we see a request to embed this construct into entries themselves.
My main ob is that how you do this seems to be aligned to the app protocol in use, as it holds sway over how you model the resources in question. My not so main ob is that over protocols like xmpp and smtp you don't seem to need feeds as much as you do over http.
cheers Bill
[ot: Danny, I'm still in delivery mode, apologies for not looking at the dates thing yet.]
