On 8/25/05, James M Snell <[EMAIL PROTECTED]> 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?
First, on this scenario, I would be inclined to make the firmware an enclosure and not included base64. But I still can see a scenario you might be serving up queries via Atom and those queries could be 'heavy'. There are, of course, several things you could do: 1. Cache the results. 2. Support ETags 3. Support ETags and 'fake' them so that they change only once a day, maybe once a week even. There are undoubtedly others, but the more important part is that your 'do not aggregate' doesn't really solve the problem. I could, for example, take one of your heavy search feeds, convert it to HTML via XSLT and include that via iframe in my home page. *That* traffic is going to be a lot worse than an aggregator subscription and wouldn't fit the definition of 'aggregation'. -joe -- Joe Gregorio http://bitworking.org