[pubsubhubbub] Re: How to check what pubsubhubbub.appspot.com is doing?

[Jay Rossiter]

I think what you're documenting is an example of bad adherence to the Atom spec more than anything else.  The self link should be the same in every document as well, because it's the "preferred URI for retrieving Atom Feed Documents representing this Atom feed".  It's the responsibility of the publisher (or publishing service) to ensure that the self link is identical for all potential URLs that feed can be retrieved at.     atom:id IRIs are per-spec not dereferencable - they're permanent, even if the feed changes domains.  How does the hub handle a subscription request for an atom:id that it has never seen before?  It doesn't know where to go to pull that feed's contents if the publisher has not set up pinging.     In my case, using atom:id adds migration problems for RSS support.  When feeds come into Pheedo, they're (mostly) not hub enabled.  We are the ones enabling hub support on behalf of the user at their request.  Since atom:id is by definition permanent, that means it really needs to be controlled by the publisher, not by an intermediary service.  If the publisher were to leave Pheedo, or inject another intermediary service ahead of us in the processing chain, the atom:id would likely change (by disappearing entirely if they left, or by the other service having to add its own atom:id for the same reasons that we did.)     Long and short - self links make sense, both to users and to the hubs.  They're meaningful.  atom:id, other than being unique to the feed, carries no information about the feed. On 10/21/2009 2:33 PM, Brett Slatkin wrote: In practice, "self" could be one of 10 URLs. Most CMSes out there will return self equal to whatever URL you happen to come across the feed. A great example is Google Reader Shared Items. Here's my feed, and it's variants. Each one is essentially the same feed, but with small differences in the URL: http://www.google.com/reader/public/atom/user%2F10577182142674084604%2Fstate%2Fcom.google%2Fbroadcast http://www.google.com/reader/public/atom/user%2F10577182142674084604%2Fstate%2Fcom.google%2Fbroadcast?ann=true http://www.google.co.jp/reader/public/atom/user%2F10577182142674084604%2Fstate%2Fcom.google%2Fbroadcast?ann=true http://www.google.co.uk/reader/public/atom/user%2F10577182142674084604%2Fstate%2Fcom.google%2Fbroadcast?ann=false ... It gets worse, considering Google has 100+ country-specific domains. So my point is, in the wild, in practice, nobody uses "self" correctly. We're setting ourselves up for failure if we expect publishers and subscribers alike to properly serve and follow "self" links. Resolving the atom:ids (which are the same for all of the feeds above) seems to work a lot better in practice. Does that make sense? On Mon, Oct 19, 2009 at 5:49 PM, Tim Bray <timb...@gmail.com> wrote: On Mon, Oct 19, 2009 at 1:30 PM, Brett Slatkin <bslat...@gmail.com> wrote: I'm doing this same "anti-aliasing" of feed URLs by using //atom:feed/id elements. The "self" link (which is in the 0.2 spec) doesn't work right in practice, methinks. Not sure how well we'll define this for 0.3 though. Really?  I thought the requirement to use the 'self' link was smart, precisely for the reason given in the spec.  What's the problem?  -Tim -- Jay Rossiter | Software Engineer/System Administrator Pioneering RSS Advertising Solutions jrossi...@pheedo.com | Phone: 503.896.6187 | Fax: 503.235.2216 Website: www.pheedo.com | RSS: www.pheedo.info/index.xml