4 ms·

In that context a feedreader (like feedburner) is a Subscriber, right? But then millions of users have still to potentially pull the data from the feedreader, b

by antpls 8y ago

In that context a feedreader (like feedburner) is a Subscriber, right? But then millions of users have still to potentially pull the data from the feedreader, because they can't implement WebSub, because they have limited connectivity and can only pull content. In the end, how is that different than a blog pushing a RSS file to a CDN?

onli 8y ago
Ah, I think I see where your problem comes from. Again, I'm not too deep into WebSub, but I know the predecessor quite well. This spec solves a specific problem. You have one URL resource many clients are interested in, that URL gets occasional updates, many clients want to fetch that new content. Think RSS feeds. so far, every client had to pull, meaning look at the file again and again and see whether there is a new update. Think a bit about that and you see how that is hard to do on client side (comparing content, making sure new stuff is really new and not just reordered, storing the old file, etc). Normally, those clients are servers. That's really important to understand, without that knowledge WebSub makes no sense. Push-based protocols solve that problem with a middleman, the hub. Whenever there is an update the original server sends one single POST to the hub, the hub then sends that notification to all subscribers. And wush, no more polling. The end result is way less traffic on the lines, way easier architecture on the feedreader side (it can be not built on a polling infrastructure, instead it just has one webhook open, and when it gets notified of an update it fetches the source once), less server load on the origin. For blogs for example that really is relevant. This has nothing to do with a CDN.
- antpls 8y ago
  Excuse me Sir, but I think you didn't understand what I meant. - With today's technology, you don't need an intermediate online, 3rd party, feedreader. Devices can pull data from the sources. - Not only devices can pull the data, but it's often the only way to get data, since mobile operators block any incoming trafic on HTTP protocol for security reasons. - People don't need to read 1000 pieces of news in real time. - With a source and a RSS reader, there is NO HUB at all. How convenient. - For relatively static content delivery problem, CDN already exists, cache exists since decades and is already part of the base HTTP protocol. - The only thing that protocol enables so far is middle-men that will try to monopolize and control the news ecosystem, while news delivery is already free (for the end user) Bonus point : the traffic of text on internet is ridiculously small compared to video and other data. That argument is not a valid one to justify introducing another 3rd party
  - krn 8y ago
    WebSub is not a RSS replacement, but enhancement. It's not created to be used by the end user directly. Such web feed management providers as FeedBurner[1] are pulling feeds from the origin no more than a few times per hour, causing a delay for the end user. With WebSub, publishers can update their FeedBurner feeds in real-time. [1] https://en.wikipedia.org/wiki/FeedBurner https://en.wikipedia.org/wiki/FeedBurner
    - antpls 8y ago
      What makes you think people want news in real time? By the way, we can also have news in real-time by pulling RSS directly from the sources, like every 2 minutes
      - onli 8y ago
        What you are proposing is by definition not real time, it is not scalable (not on the source side, not on the client side, and not traffic wise), and it is not fast enough for things like getting notified of a new chat message where this scheme can be used as well. And people do want real time there, and often enough for news as well.
        antpls 8y ago
        So basically, this is IRC, but the initial authors were removed, and the whole thing is less efficient because it runs over HTTP. At some point you have to go outside of the HTTP world and look for what already exists rather than reinventing the wheel. Does it solve news delivery ? RSS do that already. Does it solve instant notification and presence notification? Lower protocols already do that with lower overhead.
  - onli 8y ago
    I'll say it straight: You really do not know what this spec is talking about, that is why you are indeed misunderstanding this. And that's the positive interpretation. By now your points amount to nonsense as they support a unsupportable position. Not one of those points has any relevance to this discussion: - This would not change - WebSub has nothing to do with mobile devices - This is not up for you to decide, and the server powering online feed reader or platforms like facebook do have a lot of data sources - That's not a point? For the type of RSS readers you are thinking about that would not change. - A CDN has nothing to do with this. - No. It is a decentralized/federated protocol, no middle man can do that. Your bonus point is invalid: The 3rd party is already there (pubsubhubbub is used in production), this is not primarily about this type of traffic reduction you are thinking about, but yes, the ressources needed to do without websub what can be done with websub on a big scale are enormous. Again, this is about enabling push architectures for server to server communication and a scalable way to achieve real time notifications. The tiny feed reader application on your smartphone is not directly related to any of this. It would not use this protocol, it can't use this protocol, and it would not stop working because of this protocol. Edit: I made this sound a bit nicer than initially. It really feels like you want to misunderstand this spec, this annoys me a bit.
onli 8y ago
> But then millions of users have still to potentially pull the data from the feedreader, because they can't implement WebSub This is worth pointing out directly: Yes, of course. You always do have to transmit the data to the actual reader. But those are users of the feedreader, they do not contact the source at all. The advantage of this scheme is that data is transported exactly as often as necessary and as fast as possible, unlike when data is polled. It has no relation to a CDN I see. A CDN would mean the source has not to handle the incoming traffic, or less of it, but a CDN does not enable push nor reduces it the traffic between CDN and feedreader server.

by antpls 8y ago

onli 8y ago

Ah, I think I see where your problem comes from. Again, I'm not too deep into WebSub, but I know the predecessor quite well. This spec solves a specific problem. You have one URL resource many clients are interested in, that URL gets occasional updates, many clients want to fetch that new content. Think RSS feeds. so far, every client had to pull, meaning look at the file again and again and see whether there is a new update. Think a bit about that and you see how that is hard to do on client side (comparing content, making sure new stuff is really new and not just reordered, storing the old file, etc). Normally, those clients are servers. That's really important to understand, without that knowledge WebSub makes no sense. Push-based protocols solve that problem with a middleman, the hub. Whenever there is an update the original server sends one single POST to the hub, the hub then sends that notification to all subscribers. And wush, no more polling. The end result is way less traffic on the lines, way easier architecture on the feedreader side (it can be not built on a polling infrastructure, instead it just has one webhook open, and when it gets notified of an update it fetches the source once), less server load on the origin. For blogs for example that really is relevant. This has nothing to do with a CDN.

antpls 8y ago
Excuse me Sir, but I think you didn't understand what I meant. - With today's technology, you don't need an intermediate online, 3rd party, feedreader. Devices can pull data from the sources. - Not only devices can pull the data, but it's often the only way to get data, since mobile operators block any incoming trafic on HTTP protocol for security reasons. - People don't need to read 1000 pieces of news in real time. - With a source and a RSS reader, there is NO HUB at all. How convenient. - For relatively static content delivery problem, CDN already exists, cache exists since decades and is already part of the base HTTP protocol. - The only thing that protocol enables so far is middle-men that will try to monopolize and control the news ecosystem, while news delivery is already free (for the end user) Bonus point : the traffic of text on internet is ridiculously small compared to video and other data. That argument is not a valid one to justify introducing another 3rd party
- krn 8y ago
  WebSub is not a RSS replacement, but enhancement. It's not created to be used by the end user directly. Such web feed management providers as FeedBurner[1] are pulling feeds from the origin no more than a few times per hour, causing a delay for the end user. With WebSub, publishers can update their FeedBurner feeds in real-time. [1] https://en.wikipedia.org/wiki/FeedBurner https://en.wikipedia.org/wiki/FeedBurner
  - antpls 8y ago
    What makes you think people want news in real time? By the way, we can also have news in real-time by pulling RSS directly from the sources, like every 2 minutes
    - onli 8y ago
      What you are proposing is by definition not real time, it is not scalable (not on the source side, not on the client side, and not traffic wise), and it is not fast enough for things like getting notified of a new chat message where this scheme can be used as well. And people do want real time there, and often enough for news as well.
      - antpls 8y ago
        So basically, this is IRC, but the initial authors were removed, and the whole thing is less efficient because it runs over HTTP. At some point you have to go outside of the HTTP world and look for what already exists rather than reinventing the wheel. Does it solve news delivery ? RSS do that already. Does it solve instant notification and presence notification? Lower protocols already do that with lower overhead.
- onli 8y ago
  I'll say it straight: You really do not know what this spec is talking about, that is why you are indeed misunderstanding this. And that's the positive interpretation. By now your points amount to nonsense as they support a unsupportable position. Not one of those points has any relevance to this discussion: - This would not change - WebSub has nothing to do with mobile devices - This is not up for you to decide, and the server powering online feed reader or platforms like facebook do have a lot of data sources - That's not a point? For the type of RSS readers you are thinking about that would not change. - A CDN has nothing to do with this. - No. It is a decentralized/federated protocol, no middle man can do that. Your bonus point is invalid: The 3rd party is already there (pubsubhubbub is used in production), this is not primarily about this type of traffic reduction you are thinking about, but yes, the ressources needed to do without websub what can be done with websub on a big scale are enormous. Again, this is about enabling push architectures for server to server communication and a scalable way to achieve real time notifications. The tiny feed reader application on your smartphone is not directly related to any of this. It would not use this protocol, it can't use this protocol, and it would not stop working because of this protocol. Edit: I made this sound a bit nicer than initially. It really feels like you want to misunderstand this spec, this annoys me a bit.

onli 8y ago

> But then millions of users have still to potentially pull the data from the feedreader, because they can't implement WebSub This is worth pointing out directly: Yes, of course. You always do have to transmit the data to the actual reader. But those are users of the feedreader, they do not contact the source at all. The advantage of this scheme is that data is transported exactly as often as necessary and as fast as possible, unlike when data is polled. It has no relation to a CDN I see. A CDN would mean the source has not to handle the incoming traffic, or less of it, but a CDN does not enable push nor reduces it the traffic between CDN and feedreader server.