search

ankurpiyush26 / pubsubhubbub

Automatically exported from code.google.com/p/pubsubhubbub
Other
1 stars 0 forks source link

Extension proposal: Canonical feed URLs for easier pinging #39

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
This is to track an extension to the base protocol.

SUMMARY:

Lots of publishers have many variants of a feed they need to publish to at
the same time (RSS, Atom, mobile, podcast, etc). It should be easy for them
to send a single publish event to the Hub and have the Hub fan it out to
all variants and subscribers.

We need a proposal on how to do this on the wiki. Essentially, each feed
would have an ID it would specify. That ID would be used to collate
different variants of a feed as the same feed from the publisher's
perspective. The hard part here is if we want to allow for collating feeds
across multiple domains, in the case feed variants have different origins.

Original issue reported on code.google.com by bslatkin on 22 Jul 2009 at 5:18

GoogleCodeExporter commented 9 years ago 
This issue is closely related to the insistence of the spec right now to have 
the
subscriber use the <link rel="self"...> URL as the one for actual subscription 
(see
http://pubsubhubbub.googlecode.com/svn/trunk/pubsubhubbub-core-0.2.html#discover
y).
In practice, subscribers aren't going to do this properly. We need something 
better.

I coded up a prototype to get around this limitation. Essentially, the Hub keeps
track of a mapping from topic URL to feed ID, and then feed ID to topic URLs
(plural!). At subscribe time, we derive the feed ID (if the topic hasn't been 
seen
before) and save it in association with the topic URL. At publish time, we 
figure out
the corresponding feed ID is, then use the reverse index to find all aliases 
affected
by the published ping.

For RSS we just use the channel link, because there's no feed ID.

Original comment by bslatkin on 3 Sep 2009 at 8:50

GoogleCodeExporter commented 9 years ago 
I believe this has been fixed by r275. I'll be rolling this out to production 
and
updating all KnownFeed instances as soon as I finish more system testing.

Original comment by bslatkin on 21 Sep 2009 at 10:19

GoogleCodeExporter commented 9 years ago 
Note that the silliness from the spec we want to avoid is:

"Per the Atom spec, the //atom:feed/link[@rel="self"] element MUST indicate the 
topic
URL for the original event stream. Subscribers MUST use the self link when 
requesting
a subscription from the hub. Subscribers MUST NOT use the original URL from 
before
following HTTP redirects to fetch the feed. This is crucial for subscribers to 
detect
feed moves.

Hubs MUST use the same URL for both the publishing and subscribing interfaces, 
which
is why only a single atom:link element is required to declare a hub. Publishers
SHOULD use HTTPS (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, 
L.,
Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” .)
[RFC2616] in their hubs' discovery URLs. However, subscribers that do not 
support
HTTPS (Rescorla, E., “HTTP Over TLS,” May 2000.) [RFC2818] MAY try to 
fallback to
HTTP (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, 
P., and
T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” .) [RFC2616], 
which MAY
work depending on the hub's policy. "

Original comment by bslatkin on 21 Sep 2009 at 10:30