> > When Friendster approached Six Apart and asked for a way to keep abreast > as to the comment activity within the Friendster Blogging network > (powered by TypePad), I turned immediately to FTE. > > In this implementation, there was actually no desire for Friendster to > gain access to the comments themselves - all they wanted was to know: > has there been a new comment posted to any of this users blog entries? > > And in actually, TypePad didn't want to add another page to be rebuilt. > We wanted to keep things as simple as possible, in order to satisfy the > customer's requirements within incurring any more development overhead > than absolutely necessary. > > FTE was a perfect fit because it allowed Friendster to monitor comment > activity quite reliably. The count attribute wasn't enough for them > because the count attribute by itself doesn't reflect accurately if a > new comment was posted (e.g. comment count is 0, new comment received, > comment count is 1, comment deleted, comment count is 0, comment > received, etc). Depending upon the poll interval of the client, it may > miss the fact that a comment was posted. > > However, the count attribute and then when attribute gave Friendster > just what they needed: enough information to know that a) a new comment > was received, and b) sufficiently (not necessary 100% accurate, but they > didn't care) accurate comment count. They used this information to send > emails to the blog owner saying, since we last emailed you, there has > been this activity on your blog. > > The Friendster link relation looks like this: > > <link rel="replies" type="text/html" > href="http://..../foo.html#comments"; > thr:when="<date>" thr:count="<int>" /> > > Notice, in this case we are pointing to the HTML page where comments can > be found - and not to another Atom feed because we don't produce a > comments feed. We simply produce some meta data about comment activity. > > Furthermore, Six Apart likes this spec as-is because it helps to reduce > the number of documents that need to be parsed in order to determine > simple details about an entry. The burden of having to fetch an Atom > document for each entry and then counting the number of entries within > that feed to derive a count, is totally absurd. If you CAN make it > easier for a developer, why won't you?
Well you simply move the burden to a different level where it is not your problem anymore, ie on the HTTP level and far from the application level. It is fine but the load will be paid by someone at any given time. > > Not to mention that in Friendster's case, this process would not have > worked for them because we didn't produce a feed for them to extract > this information from, because their requirements forbade it. > > I have gone on long enough. I am hoping this gave some good background > around a real implementation and use case currently in use today. You did and I thank you for sharing this information. That being said, I raised two points in me original mail: 1. The fact I thought the thr attributes were useless. You made a good case and I will not fight against their use on the application level anymore. We are therefore fine on *that* level. 2. The burden added to the HTTP layer. I'll try to make myself clear. In your implementation above you have to update the Atom feed to modify the thr attributes. The problem is that you have then to update the last modified date of the resource (as in the REST definition of resource) itself (whether you generate ir on the fly or save it on disk). For aggregators which are aware of the FTE, it won't be so much of a problem as you showed me because they will know how to deal with that on the application level and make the best of it. However, there will be clients which won't care about the semantic of the resource, their point is simply to fetch a resource and cache it as long as it is not modified. By acting as you do, we may end up in a huge amount of feeds being sent on the wire to clients which believe the feed has actually changed in its content when it has changed only in one meta-data value (that they will not handle anyway). This is my grief. Your use case is great at the application level but could really mess bandwith usage as well. That's why I also say you have moved the burden down to one level so that it doesn't make your life more complicated and so that others pay the price of it. I'd be interested to hearing from Friendster about their feed bandwith usage since you have setup the FTE. However I'm not blind enough either to realise my algorithm would not be much better in some circumstances. I guess my problem is that the semantic conveyed by those attributes should belong to a push protocol and not to a pulled one like HTTP. I aslo understand that Atom and its extensions are not protocol aware. They should not have to care about HTTP. It does not mean though that we cannot think about their implications in those areas. Thanks for your feedback. - Sylvain
