View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 1337 | Composr | syndication | public | 2013-08-07 15:46 | 2020-03-22 20:16 |
| Reporter | Chris Graham | Assigned To | Guest | ||
| Priority | normal | Severity | feature | ||
| Status | new | Resolution | open | ||
| Summary | 1337: WebSub (PubSubHubbub) support | ||||
| Description | Implement support for WebSub (previously named PubSubHubbub) in addition to the existing RSS cloud support. | ||||
| Additional Information | Google are preferring PubSubHubbub. I had an exchange with a Google engineer on Techcrunch.com when PubSubHubbub was released, and they had not even heard of the official RSS cloud feature when they were designing PubSubHubbub - now it's political, as Google are pushing their own standard (grr...). | ||||
| Tags | Type: Mobile, Type: Performance | ||||
| Attach Tags | |||||
| Time estimation (hours) | 5 | ||||
| Sponsorship open | |||||
|
|
Feedly uses pubsubhubbub, but does not currently support Push Notifications. I imagine at some point it will, at which point this will be an effective notification system when the web_notifications RSS hook is connected through to it. |
|
|
If implementing this we should drop the RSS cloud feature. I don't think anyone on the Internet is even using it. Few people use PubSubHubbub explicitly, but at least it is supported by Feedly, which is the leading feedreader. |
|
|
PubSubHubbub should be implemented as a background task, unlike the current RSS cloud implementation. |
|
|
Looking at this again, I can see that WebSub isn't really very open. The ping protocol between hubs and publishers is not defined - just the protocol between hubs and clients. "The specific mechanism for the publisher to inform the hub is left unspecified. For example, some existing public hubs [1] [2] [3] ask publishers to send a POST request with the keys hub.mode="publish" and hub.url=(the URL of the resource that was updated)." [https://www.w3.org/TR/websub/#publishing] I'm not sure exactly why we'd want to implement 3rd party companies personal standards in Composr. It seems a bit bizarre to me, handing off control to the private companies who are choosing to implement hubs - the W3C should have properly specified it. The whole advantage of WebSub over RSS Cloud is that the heavy lifting is off-loaded to the hub. So we can't realistically implement a hub ourselves as that defeats the whole point. But if we implement for some company's specific hub protocol, we are not being open. The only reason I could see to implement private companies WebSub ping protocols is if our implementation of RSS Cloud really was being overwhelmed by lots of users requesting to be pinged about updated resources at the same time. This has never been a problem, and I don't expect it to be - as there are only a handful of feed readers out there that are going to implement subscription to an RSS Cloud server (Feedly?) - and few people use RSS anyway. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-06-21 19:15 | Chris Graham | Note Added: 0005977 | |
| 2020-03-22 20:05 | Chris Graham | Summary | PubSubHubbub support => WebSub (PubSubHubbub) support |
| 2020-03-22 20:05 | Chris Graham | Description Updated | |
| 2020-03-22 20:16 | Chris Graham | Note Added: 0006480 |
