[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Don't mess with HeadInEntry!




On Friday, February 4, 2005, at 01:29 AM, Bob Wyman wrote:
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.

It seems to me that the main reason for the objections to "feed of feeds" was that it seemed to open the way to unlimited recursion. I too am a little surprised to see proposals for recursive feeds of feeds--that's what sparked the idea of the Aggregation Document you've taken such a disliking to.


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

I suspect that the large volume of proposed text that PaceAggregationDocument lifted from PaceFeedRecursive made it look a lot more drastic than it really is. In both of those proposals, the proposed text was largely identical to what's in the current draft--it's just been moved around and one or two little changes made. However, there is a point to the argument that we should minimize how much mucking around with do with things right now, so I've posted PaceAggregationDocument2, which only proposes the changes necessary to create an Aggregation Document.


As for HeadInEntry, the best argument I see for it if we adopt a containment-based aggregation mechanism is that Entry Documents may need to be able to refer to their feeds for context. I can think of three ways to handle that:

1) A link to their feed
2) Use a one-entry Feed Document instead of an Entry Document
3) Allow HeadInEntry in Entry Documents only