Robert Sayre wrote:
> HeadInEntry is trivial to do as an extension, so there's no
> reason to leave it in.
There are a number of excellent reasons to leave it in!
1. Just about the only functional "advantage" that Atom has over RSS
is that HeadInEntry provides core support for aggregated feeds. If you're
unwilling to innovate in even this one tiny spot, why the heck bother with
this effort at all? Perhaps we should all join Dare over in RSS-land... With
Microsoft being so anti-Atom, we need *some* argument for expending the
effort and political capital needed to support this format!
2. The Internet Draft "Atom over XMPP" requires HeadInEntry in order
to provide attribution for entries.
3. Entry Documents will often need HeadInEntry to identify their
origin.
4. We've been talking about HeadInEntry ever since I proposed it
back in June at the Atom Community meeting. On numerous occasions, the group
as a whole has rejected the various "feed of feed" proposals as overly
complex and unnecessary. It is a bit bizarre to see all this being rehashed
in a rush as we drive towards a Last Call.
5. If HeadInEntry is not in the core, it will not be widely
implemented by clients. Given the speed with which the IETF approves RFC's
it is also likely that it would be a *long* time before an extension RFC
could get approved -- yet we need HeadInEntry TODAY! The reduced penetration
of HeadInEntry that would come from it being defined in a future extension
makes it largely useless and not worth the effort to even try to get a
formal extension. What you'll be doing is forcing people who are in the
aggregation business to define private extensions to address these issues
and to do so outside the Atom process. We have work to do and customers to
serve. We can't just put our businesses on hold for years...
6. All of the alternatives that have been proposed require drastic
and unlikely modifications to the design and architecture of readers. (i.e.
stuff like adding an aggregation document!!) Such proposals are not viable
alternatives no matter how sweet one might find their abstractions...
7. We at PubSub have had "running code" since July that demonstrates
the utility of HeadInEntry (i.e. our "ps:source-feed"). None of the other
proposals that have been made are supported or "proven" by running-code.
There is no field experience in their use. I have also not seen any
alternatives proposed by anyone who actually appears to be in the feed
aggregation business...
We decided to support HeadInEntry. It doesn't make sense to back off
now. Deferring HeadInEntry to a non-core extension essentially kills it and
ensures that Atom use will provide virtually no advantage to anyone who is
building aggregated feeds.
bob wyman
