BlogEd [1] is a thick client blog editor. I am currently writing a link from bloged to Roller [2] using the MetaWeblog API. Being able to get the complete feed state is very important for a tool such as BlogEd if it is to correctly synchronize the state of its entries with those on the server.
To illustrate this imagine the following situation:
1. Joe Blogger writes a few entries E1, E2, E3 in his blog editor
2. Joe Blogger publishes these on the remote server as RE1, RE2 and RE3
3. The next day Joe goes on a month long trip around Europe without his computer and writes up lots of cool blogs from internet caf�s using the Roller web interface. These entries called RE4, RE5, RE6, RE7, ...
4. During the trip Joe may not just add new entries, but update the state of already written ones, such as RE1 to RE1version2
5. Back home after his trip Joe would like to synchronize the state of his blog editor with what he wrote in Roller, so that he can continue to use the advanced features of his thick client interface.
I think at stage 5 Joe would be very disappointed if a few of his entries went missing because the feed did not keep a full history of the changes to the entries. Even more, Joe would probably like to keep up with this change history to any of the entries, so that he can himself keep an idea on how his entries changed over time.
I think this illustrates very clearly why keeping feed state is very important. With the MetaWeblog interface I may be able to get this information, but there really is not guarantee that I will be able to do it.
Henry Story
[1] https://bloged.dev.java.net/ [2] http://www.rollerweblogger.org/
On 21 Nov 2004, at 17:46, Mark Nottingham wrote:
"Reconstructing Feed State", seems to me to be expecting rather a lot of the client, to remember every change and every feed head.
It doesn't have to remember every change; it just has to remember the last feed 'this' URI that it saw, so it can walk its way backwards to it.
I wouldn't have though a warning should be needed in its absence. Under
what circumstances would the client actually want to reconstruct feed
state? My guess is that would fall outside 80/20 applications.
Most aggregators do it today; they're just sloppy about it (because they don't have a mechanism like this). To me, the most boring aggregators are those built into browsers that don't keep state. To me, the warning is absolutely critical; it raises the guarantee you get with Atom, and differentiates it from RSS substantially.
