The H-series Madsen has responded at length to my post concerning living in a world with obsolete data. Naturally I disagree with his response as it's otherwise hard to have an argument ("You're right!", "Yes, and so are you, damn you!"). Let's consider his example.

He states that he's relying on an RSS feed to give him news about a situation of concern (I consider the topic to be in somewhat poor taste, so I'm going to skip the specifics). He is worried that due to slow updates or caching further information of relevance may be ignored. He feels this to be a problem with the RSS model, and to some extent it is. However I believe it's more an issue of his (theoretical) usage of the data and his expectations of the mechanism.

The item from RSS will have a timestamp associated with it. In Google Reader (my current blog reader) this is a time for items published today and a date otherwise. In the theoretical situation this is sufficient information for Brian to realise that he has obsolete data. That the data is obsolete is a perfectly legitimate condition to consider when making a decision. Deciding to obtain news via a different channel that may be more up to date is an entirely legitimate strategy, but it still rests on an understanding that your data is obsolete.

As I mentioned in a comment on his previous post RSS is a pull mechanism and hence involves polling. To counter the inefficiency this causes various strategies such as caching are employed that reduce the load and traffic involved in supporting multiple clients. Web based clients like Google Reader may also increase efficiency by storing content and supplying it to multiple users. All of these things involve latency. This makes RSS a poor mechanism for distributing time sensitive information. A push system would be more effective but would be more difficult to establish. The advantage of RSS is that it can work on top of existing web protocols. Push to transiently connected clients is a more difficult proposition, especially where clients join and remove themselves from notification channels.

I would further argue that understanding that data can be obsolete is far from the status quo and a more naive view where developers and users of the data just accept it predominates. I also wonder about the statement "Not blindly accepting that data is obsolete just because it is.". I fail to see how recognising data is or has the potential to be obsolete is doing anything blindly. In many cases it would be a definite improvement. It's certainly not the only criteria of relevance but it can be a very important one. I believe "There is no guarantees in the world" was basically my entire point and that I was suggesting that systems be aware of this rather than the entirely optimistic model that so often predominates.

I'm certainly sorry that you feel Brian's blog software is letting him down but as I previously stated I don't believe your suggested fix to be a good one. In a slow conversation the likelihood of alteration while a comment is being written is low. In a fast moving conversation then there will likely be changes every time a comment is submitted. This gives a disincentive to post a significant comment, or indeed a comment at all. This is essentially trying to get sequential behaviour from sources that operate simultaneously and independently. I believe comments threads work best without this. The appropriate solution is still to have a compensation mechanism to allow for cases where other comments or edits to the post invalidate part or all of a comment. This is necessary anyway for comments or alterations after a own comment. The current mechanism is simple and obvious: post a follow up comment.

Middle ground may be for blog software to update the content without losing the comment. But this still will not eliminate others commenting simultaneously and forcing a "first poster wins" model is just going to anger people. The blagosphere has done fairly well so far with this model and I'm unconvinced that a better model has yet been proposed. Certainly improvement is possible and desirable but in suggesting improvement we must consider whether the proposal is an improvement overall.

In other contexts checking for changes is an entirely legitimate model. For instance updating customer details (including their address) should not succeed if between the user obtaining the details and updating them another change has been made. This is standard optimistic concurrency. The difference here is the mode of operation. In this scenario it is unlikely that two users will attempt to update the same customer record simultaneously and blocking the second user is legitimate due to rarity. On a blog many people will be attempting to add to the comments, but each comment is additive and does not alter the content of other additions. There may be a human context where commenters would prefer to have waited until they could have read the comments of another. But this again leads to paralysis because there is no plausible mechanism whereby they can know when a random group of individuals has finished commenting in order to determine that they may now start.

Have at you, Bwian!