Eric Scheid wrote:
>> <origin href="..." type="application/rdf+xml" title="My RDF Feed"/>
>ah, but now you do have the @href, so it won't be hard to go fetch it
Actually, it would be quite a burden. You would have to fetch the
full source feed for every entry in the aggregated feed just to pick up a
few header elements. Given that many feeds contain 20, 30, or more items,
and it isn't possible to fetch less than 100% of a feed given HTTP, you're
going to be wasting more than 10 times as much network bandwidth then would
be used if the <head/> elements were simply inserted into the entries.
Some will argue that you could "cache" header data you've seen for
various "origin" feeds. However, if the entries inserted into the feed come
from a large pool of feeds (like the millions that we filter at PubSub),
then you're going to find that the vast majority of entries in the feed will
be appearing for the first time or will appear so infrequently that cached
data will have expired. Thus, the solution you propose, fetch the feed to
pull in the contents of <head/>, turns the system into nothing more than a
poorly and inefficiently built ping based system. i.e. the contents of the
aggregated feed really should be reduced to nothing more than an atom:id and
the origin URL. Since you're going to fetch the feed anyway, why bother
having any more data in the aggregate feed?
I still contend that atom:origin does nothing useful for aggregated
feeds. Origin, even if extended as you propose, just doesn't address the
issues in a reasonable fashion.
bob wyman
