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

Reply via email to