There's a Reason RSSCloud Failed to Catch On
workbench.cadenhead.org
There's a Reason RSSCloud Failed to Catch On
1–10 of 20 posts
Re: There's a Reason RSSCloud Failed to Catch On
#2I think a more fundamental reason is that RSSCloud solves the problem "I used to use RSS to read articles, but the 15 minute delay between the article being posted and me being able to skim it in my RSS reader was unacceptable" and that this is a problem real people do not have.
Re: There's a Reason RSSCloud Failed to Catch On
#3I think a more fundamental reason is that RSSCloud solves the problem "I used to use RSS to read articles, but the 15 minute delay between the article being posted and me being able to skim it in my RSS reader was unacceptable" and that this is a problem real people do not have .
Not quite. It's a problem they don't have any more. If RSSCloud had been supported from the start, I doubt Twitter would have been invented, because everyone would have just "microblogged" from their actual blogs in realtime.
Re: There's a Reason RSSCloud Failed to Catch On
#4I think a more fundamental reason is that RSSCloud solves the problem "I used to use RSS to read articles, but the 15 minute delay between the article being posted and me being able to skim it in my RSS reader was unacceptable" and that this is a problem real people do not have .
I think the problem it really solves is the Twitter problem rather than the RSS reader one. That is, if RSSCloud works as advertised, implementing a Twitter-scale infrastructure becomes pretty simple.
The article raises important issues re scaling, though I'd expect Wordpress and Winer are aware of them. I guess it remains to see if they are (and if Twitter-like apps are something people actually want)
Re: There's a Reason RSSCloud Failed to Catch On
#5The proposal never made sense. Most people don't use desktop feed readers and even if they did this solution wouldn't be scalable (as Cadenhead mentioned). Google Reader knows when you update your feed because you already ping Google. In my experience they are grabbing the feed in a few seconds anyway--it's up to them to show this to users in real time if they want to but there is nothing stopping them.
It seems like Dave wants to continue using his out dated desktop software (the OPML Editor) to view feeds in a manner much better suited for a hosted product. That might be great for him, but I'd rather not change publishing on the internet so his decades old software can keep pace with Google Reader.
Re: There's a Reason RSSCloud Failed to Catch On
#6RSSCloud or not -- I do happen to think that we need a push RSS solution -- what really bugs me is the fact that once again, we're inventing different standards to do the exact same thing. As if ATOM vs RSS wasn't enough, now we have RSSCloud + PubsubHubbub to worry about. PSHB already has Google behind it (all of Feedburner feeds support it), so I really fail to see what wordpress won by adopting RSSCloud.
Besides, while Dave is a brilliant guy, PSHB already has a lot more people working on it with open source hub and client implementations (heck, I wrote one for Ruby!).
Re: There's a Reason RSSCloud Failed to Catch On
#7The proposal never made sense. Most people don't use desktop feed readers and even if they did this solution wouldn't be scalable (as Cadenhead mentioned). Google Reader knows when you update your feed because you already ping Google. In my experience they are grabbing the feed in a few seconds anyway--it's up to them to show this to users in real time if they want to but there is nothing stopping them. It seems like…
The proposal has the potential to support pooling of multiple feeds. For example, you can get the updates of thousands of feeds in one request. That saves a lot of bandwidth and processing time. Does that make sense?
Re: There's a Reason RSSCloud Failed to Catch On
#8RSSCloud is useless, for increasingly ridiculous reasons:
10e2 It's idiotically-designed
(he thinks traditional SOAP posted to a resourcey URL is REST!)
10e4 It doesn't help centralized aggregators scale at all
10e8 It doesn't work with NATed clients
10e16 It was specced/never-implemented/forgotten by Dave Winer 8 years agoRe: There's a Reason RSSCloud Failed to Catch On
#9The proposal never made sense. Most people don't use desktop feed readers and even if they did this solution wouldn't be scalable (as Cadenhead mentioned). Google Reader knows when you update your feed because you already ping Google. In my experience they are grabbing the feed in a few seconds anyway--it's up to them to show this to users in real time if they want to but there is nothing stopping them. It seems like…
The proposal has the potential to support pooling of multiple feeds. For example, you can get the updates of thousands of feeds in one request. That saves a lot of bandwidth and processing time. Does that make sense?
The client would still have to be publicly routeable!
Re: There's a Reason RSSCloud Failed to Catch On
#10Here's my understanding of the potential for a scalability problem.
EXAMPLE: twitter.com has 24,650 twitter followers. If Dave gets 24,650 followers on an RSSCloud architecture then this is what happens when he posts.
1. Dave creates a 140 char post. Hs blogging software sends a notice to the cloud server that he has an updated RSS feed.
2. the cloud server sends update notices to the 24,650 subscribed "listeners" to Dave's "RSSCloud-twit-sream".
NOTE:It does not send Dave's new post text just the alert event.
3. the 24,650 listeners then do an RSS GET from Dave blogging server. This could create "cattle stampede" (i.e. slashdot effect) and many users may not get service when Dave's server is overrun. The server would likely be swamped with this massive interest in Dave's blog in a few seconds from these real-time subscribers.
At small levels of users the architecture is effective and elegant. At very large numbers it's missing an essential optimization. Only the "new blog" text should needs to be sent... maybe with the RSSCloud event for example.
An RSS GET will pull the whole string of recent blogs posts for all 24,650 users. A lot of excess text that most users already have from being real-time listeners anyway.
The RSSCloud Blogger's software needs to see a difference between a RSS GET for the recent blog text and an RSSCloud GET for the latest update text ONLY. Reducing the amount of text being sent out but a change to the protocols as described I think.
Of course, I could be way off base but I'm really trying to understand the overall architecture and the "realtime" problem this is intended to resolve for us all.
NOTE: If you federate the RSSCloud servers you just make the "GET" problem even worse. More demand on the blogger's RSS feed in a few seconds. It's like a user driven "slashdot effect". Post a 140 char message and notify the cloud and boom... you're server falls over.
I'll await corrections to my understanding.
NOTE: PubSubHubBub has an entirely different approach to the real-time optimization for bloggers. The Hub Server gets the blogger's new post text and the Hub Server forwards this delta to subscribed listeners. The Blogger's server never sees any excess traffic in or out. Of course, the PubSubHubBub service could require the resources of a Google, Amazon or Yahoo. A centralized service that could potentially have a "fail whale". Dave's RSS Cloud has a million "fail fishies".
Life as always is rife with tradeoffs. Go figure. YMMV.