RE: PaceHeadless

[Bob Wyman]

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

[Walter Underwood]

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

[James M Snell]

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

[Eric Scheid]

 PaceHeadless

-1

Re: PaceHeadless

[Eric Scheid]

-1 atom:feeder is ugly

Re: PaceHeadless

[James M Snell]

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

[Robert Sayre]

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