RE: PaceHeadless
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
RE: PaceHeadless
--On Tuesday, February 08, 2005 08:39:42 AM -0500 Bob Wyman [EMAIL PROTECTED] wrote: 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. +1 The feed document *must* be standalone. Everything required to interpret the feed has to be in the feed. wunder -- Walter Underwood Principal Architect Verity Ultraseek
Re: PaceHeadless
Well, I ain't gonna argue the point, but I'm going to stick by the assertion that feeder/head is ugly. Any use of this stuff I plan to make can live equally well with either approach. - James M Snell Walter Underwood wrote: --On Tuesday, February 08, 2005 08:39:42 AM -0500 Bob Wyman [EMAIL PROTECTED] wrote: 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. +1 The feed document *must* be standalone. Everything required to interpret the feed has to be in the feed. wunder -- Walter Underwood Principal Architect Verity Ultraseek
Re: PaceHeadless
PaceHeadless -1
Re: PaceHeadless
-1 atom:feeder is ugly
Re: PaceHeadless
Agree, feeder is ugly. but head should still go away. My preference would be a link based alternative. feed ... entry ... link rel=feed href=... / /entry /feed - James M Snell Eric Scheid wrote: -1 atom:feeder is ugly
Re: PaceHeadless
Graham wrote: -1 Putting everything in one group and requiring it to be first is useful, and also adds consistency to head-in-entry, as evidenced by the introduction of the feeder element. Also feeder is a horrible word. And head doesn't suck? I struggle to type a sentence on the subject without making an unintentional pun. source-feed is fine. The section on atom:head is totally confusing and bad--it's easier if you just do it the way PubSub does it *right now*. Robert Sayre