On Thursday, August 25, 2005, at 12:25 AM, James M Snell wrote:
Up to this point, the vast majority of use cases for Atom feeds is the
traditional syndicated content case. A bunch of content updates that
are designed to be distributed and aggregated within Feed readers or
online aggregators, etc. But with Atom providing a much more flexible
content model that allows for data that may not be suitable for
display within a feed reader or online aggregator, I'm wondering what
the best way would be for a publisher to indicate that a feed should
not be aggregated?
For example, suppose I build an application that depends on an Atom
feed containing binary content (e.g. a software update feed). I don't
really want aggregators pulling and indexing that feed and attempting
to display it within a traditional feed reader. What can I do?
In that particular use case, I'd expect entries something like this:
<entry>
...
<title>Patch for MySoftware</title>
<summary>This patch updated MySoftware version 1.0.1 to version
1.0.2</summary>
<content type="[...whatever goes here]">k3jafidf8adf...</content>
</entry>
Looking at this, my thoughts are:
1) Feed readers that can't handle the content type are just going to
display the summary or title anyway, so it's not going to hurt anything.
2) People whose feed readers can't handle the patches probably aren't
going to subscribe to this feed anyway. Instead they'll subscribe to
your other feed (?) which gives them a link to use to download the
patch:
<entry>
...
<title>Patch for MySoftware</title>
<summary>This patch updated MySoftware version 1.0.1 to version
1.0.2</summary>
<link rel="[???]" type="[???]" href="..." />
</entry>
I don't think we need anything special to tell aggregators to beware
content that they don't know how to handle in this feed. That should
be marked clearly enough by @type. More in a separate message...