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...

Reply via email to