James M Snell wrote:
> My preference would be a link based alternative.
><feed>
>   ...
>   <entry>
>     ...
>     <link rel="feed" href="..." />
>   </entry>
></feed>
        I'm tired of arguing this one, so, I'm just going to say this one
more time and leave it at that.
        Linking to the feed is not an acceptable solution. It must be
possible to embed feed metadata in an entry in a feed and in an Entry
document. 
        Users and their news aggregators expect to have access to source
feed title, author, etc. when entries or lists of entries are displayed. If
the feed metadata is not in the entries, then it will have to be fetched
before entries can be displayed to the user. Thus, we should expect that
whenever a feed is received that contains links to feeds, the aggregators
will immediately generate a storm of HTTP request to pull down the full
feeds which are linked to simply in order to extract the feed titles and
other metadata. The result will be bursts of network traffic. Most of the
bandwidth consumed will be an absolute waste. (i.e. Many feeds in the wild
today are as large as 100K bytes. You're suggesting a design that requires
all 100K bytes to be pulled down in order to extract a few bytes of title
data. This is silly.)
        If Atom drops HeadInEntry (or the alternative equivalent mechanisms
such as feeder) and replaces it with a link to feed, we at PubSub will
simply not be able to use Atom as defined. Other providers of aggregators,
search engine results, synthetic feeds, etc. will come to the same
conclusion in time.
        Have a good day. I'm sure you'll all be pleased to know that I won't
be bothering you about this in the next few days. Do what you will...

                bob wyman
 

Reply via email to