On Wed, Oct 21, 2009 at 5:34 PM, Tim Bray <[email protected]> wrote: > It's arguably a shortcoming of atom:source that it > doesn't handle multiple levels of nesting. This is a known limitation of Atom that was discussed by the Working Group at some length and on multiple occasions. Each time it was discussed, the WG decided to leave things as they were. (The general issue discussed went under the tag "provenance".)
The general issue is that when you copy an entry from any feed document other than that feed document whose metadata is in the entry's atom:source, there is no way to indicate from which feed document you copied the entry unless you insert some extension element. Of course, if you add an extension element, you'll might be breaking a signature... So, you probably don't want to do that. One line of reasoning says that this is not a big problem. As is often noted, Atom is supposed to be about entries, not feeds. Thus, the *important* feed to associate with an entry is its source feed -- not the feed where you happened to stumble across the entry. Atom, as defined, satisfies these people. Others will argue that it *is* important to know not only the source feed but *also* where you found the entry. This tends to lead people to want to record "provenance" or insert into an entry a list of feeds and/or locations (entries can live outside a feed) that record all the places that an entry has been found as it is copied around the network. Atom, as defined, does not satisfy these people. bob wyman On Wed, Oct 21, 2009 at 5:34 PM, Tim Bray <[email protected]> wrote: > > On Wed, Oct 21, 2009 at 2:13 PM, Brett Slatkin <[email protected]> wrote: > > >> Seems to me that the client model for processing a single vs. > >> aggregated distribution might be quite a bit different. And also, the > >> original upstream feed might have used entry/source already (this > >> makes me nervous about the whole notion of PuSH co-opting <source> for > >> its own purposes). > ... > > This is the first time I've heard someone point this out. I believe > > the atom:source element was specifically included in that spec for the > > purpose that PubSubHubbub is using it. Bob Wyman seemed to indicate > > the same thing too in some other email threads on this list. Could you > > clarify how this is "co-opting" the source element? > > Well, consider the popular feed at > http://planet.intertwingly.net/atom.xml - it's already an aggregation, > produced by the well-known "planet" software, and makes heavy use of > the <source> element. What happens when PSHB tries to combine this > and several other feeds? > > It's arguably a shortcoming of atom:source that it doesn't handle > multiple levels of nesting. But I also think it's a mistake for PSHB > to assume that it's the only link in the aggregation chain. > > >> [Um, when I read this section, there's a little voice in the back of > >> my head shouting "YAGNI!"] > > > > I disagree with "YAGNI" here. Take world-wide RSS traffic. Multiply by > > 1,000,000. We will need aggregated delivery to fully utilize links. > > You're entitled to your opinion, but I think you should get it working > first and discover your bottlenecks by experience, rather than invent > something to fix a problem you're pretty sure you're going to have. > Following this advice is easier for me than for other people because > repeated humiliation has taught me that I'm not smart enough to > predict where the choke points are going to be in things that approach > internet scale. > > Anyhow, the <source> element strikes me as a lousy solution. It's > going to bulk up your feeds pretty severely, unless I'm missing > something. Why not just have a > > <pubsubhubbub:divider src="http://wherever..."; /> > > separator element here and there among the entries? Or jam a bunch of > feeds together with multipart/related (works great, lots of > libraries)? -T >
