> However, if I'm an aggregator I don't need the thr:count and thr:when
because I will find
> those information anyway with the following process:
>
> 1. I fetch the comment feed and put it my cache 2. I want to know if a
new comment has
>    been posted, I won't fetch the feed containing the entry but the
feed containing the
>    comment
>  a. No comment added => 304 Not Modified
>  b. A comment added => I fetch the feed again and know both the number
of comments and 
>     the date of the latest one

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?

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.

Caveat: Six Apart didn't implement this extension with ANY assumption
that it would remain as-is. James warned me that it could change - and
in fact it did. We implemented it knowing full well it wasn't final. But
despite the risk of it not being final - it was still the best solution
on the market.

Byrne Reese
Manager, Platform Technology
Six Apart, Ltd.

Reply via email to