RSS is Push
One comment has come up every time I’ve given my RSS, ATOM, OPML, and All That talk. As soon as I describe RSS/Atom as “push”, I know a hand’s going to shoot up and some techie is going to say, “But isn’t the feed reader polling the server every 30 minutes to pull down the content?”, and my response is always, “Yes, it is; but that’s irrelevant.”
The issue is one of point of view, and the only point of view that counts here is the user’s. The user does not have to take any extra action to get the updated content. It shows up in their reader automatically. This is push. From the user’s point of view, they are not pulling anything. The user really doesn’t care how the different combination of software running on their machine and the server interacts to push the content to them. All they care about is that happens without any effort on their part. In fact, it’s possible to imagine a serverside blog client that does automatically push updates to a browser client using server push or AJAX. I doubt that would be as nice an experience as the current clients, but there’s no technical reason it couldn’t work.
RSS is push just like e-mail is push. Whether you use Eudora, Outlook, or Thunderbird; POP or IMAP; the messages actually get into your inbox because your client goes out and pulls down the messages from the server. (They may be pushed onto the server in the first place, but they’re always retrieved via pull.) As long as the e-mail client pulls down the messages without a specific use request or action, it looks to the user like push and that’s all that matters.
May 2nd, 2006 at 11:54 am
I’d agree that you shouldn’t need to know the specifics of how a client-server interaction takes place in order to label that interaction in a user-meaningful way. This, however, is silly. You assume that the user can’t remember what he requested, and that every trip to his inbox and/or aggregator is an excercise in exploration and discovery (“Hey, how’d this stuff get in here?!”).
In fact, I’d go so far as to say the opposite, that users sometimes view e-mail as pull. To see why, go ask a common user why some piece of information showed up in their aggregator or inbox. For RSS, the answer is universally “Because I asked for it.”, and that pretty much defines “pull” to the user, regardless of the machine-level interaction. For e-mail, some things like mailing lists will elicit a similar answer “Because I signed up for it.”.
However, most e-mail would garner the response “Because someone sent it to me.”. To users, this defines “push”. There is nothing in the delivery mechanism that makes any difference to how they view their reception of the content in question.
October 25th, 2008 at 7:45 pm
If the client in a polling system doesn’t poll the server fast enough, and the server expires older messages, then this “pull” mode will possibly miss some messages. In contrast, a “push” system will deliver every message to the subscriber service (listening for message deliveries), unless there is an overflow that would again drop some messages. So both modes are similar in that way too.
But how fast is fast enough for polling? A push system with sufficient buffering seems superior in scalability, provided all the messages are wanted.
January 29th, 2009 at 9:17 pm
Perceiving RSS as push technology requires an assumption of connectivity. If I go to my handy RSS reader and I don’t have a connection to the content source, especially if I haven’t had a connection in a while, the resulting list of outdated articles will quickly shape my perception to that of pull rather than push.
June 30th, 2009 at 11:15 am
[…] Push und Pull sind hier offenbar nicht so ganz verstanden worden. RSS ist eine PUSH-Technologie. Nur Techhies bezeichnen es als Pull, weil der Client die Meldungen rauszieht. Aus Sicht des […]
July 6th, 2009 at 4:35 pm
[…] ist der laufende Emailclient, SMS im Handy und eben auch abonnierte RSS-Feeds (vgl. Beitrag “RSS is push”). Das gleiche Verständnis steckt auch hinter dem als Innovation gefeierten „Email-Push“ beim […]
July 15th, 2009 at 10:18 am
Clearly one of the different between PUSH and PULL and how quick you get the information. Like Blackberrry, people expect to get information right away with PUSH. If I get a email, I want to know the moment it arrive at the server. Cleary, RSS is PULL since when the RSS feed has any updates, I won’t know right away until I pull the information from the server. If the client set it to ‘pull’ from the server only one a day, then I will have information that may be 1 day old!!!!!
Again, the big different between push and pull is how quick you get the information without factor in how ofter you poll the server. Of course if you poll the server every second, you may get the information just as fast but you are just wasting network bandwidth compare to push method.
August 7th, 2009 at 6:32 pm
It reminds me of my high school physics teacher claiming that there is no such thing as (mechanical, as opposed to gravitational, etc) “pull”–there is always something on the other side “pushing”. Of course this is insightful, and fun, but does not operate on the basic concept that a person has–“pull” means acting on something to bring it closer to one’s self.
The same is here in terms of conceptual thinking–if the user does not need to be cognizant of polling occurring on one’s behalf, then yes, RSS is effectively “push”…
August 28th, 2009 at 4:34 am
[…] very confusing for me, why RSS was announced as a push technology. I had to read several articles (e.g.) about the topic until I came to a shocking […]
October 3rd, 2009 at 6:55 pm
Both Thunderbird and Windows Live Mail support PUSH the “geek” way. You can configure them to leave a connection to the server open so that when a message gets there, the server pushes them to the client instantly (Se IDLE in the IMAP protocol).
RSS is not push no matter how you put it.
January 21st, 2010 at 3:14 am
RSS and Email are not push based on your definition. The reason… push is when the server calls the client to deliver the info.
Geek or no geek everybody has at some point been with someone on the phone asking the question… Did you get my email? -Not yet, how about now?, not yet…
Chances are that when there is real push involved the info gets delivered faster and that affects all users regardless of their tech knowledge.
July 1st, 2010 at 5:33 am
One account, two different email programs. Configure the first email program to pull emails every 15mins. Configure the second one to “Push-IMAP”. Then you will notice the difference between “push” and “pull”.
Pull just means getting things LATE while the Push guys are getting it instantly.
July 20th, 2010 at 1:27 pm
RSS servers do not need a list of subscribed users – they only wait for anyone to connect. From a techie perspective, that makes RSS a PULL technology.
From a non-techie perspective, RSS readers (the humans, not the software) won’t see any feeds until they go subscribe to them. This also sounds like PULL to me – you figure out what you want, and your computer shows it to you.
From the perspective of a publisher, it might get a little more fuzzy – you create content and publish it, and your subscribers see it. That feels a lot like PUSH, but really it is only PUSH from the publisher to the RSS server. The publisher cannot use RSS to send to anybody – they can only use it to put stuff out there. Much the same as publishing with traditional HTML. The major difference is just that RSS gives users more efficient ways of PULLing.
As for the benefits of one method over another… PULLing is best for on-demand content (web pages). PUSHing is best for sending a person info he doesn’t know he wants (telephone, fax, email, etc).
The question of push vs. polling is a whole different animal, and has more to do with technological constraints. Pushing data is more efficient when possible, because it only needs to happen when there is data ready to send. Polling uses more resources (by constantly checking when there is no new data), but is the only way for PULL services, and for when firewalls and network architectures prevent connections from being made directly to client machines (which is nearly always the case now).
November 16th, 2010 at 3:49 pm
I’m sorry but eventual delivery is clearly not all that matters to users. Users are very conscious of what costs them time and I can guarantee you that they will notice a 30 minute lag between arrivals. Having the RSS reader poll the server for new messages drastically reduces its usefulness as a notification service of any kind.
RSS is not a PUSH technology. Period.
July 9th, 2020 at 11:11 pm
This has got to be the stupidest texh article I have ever only quarter read. PUSH is not PULL. You may have deluded yourself into thinking that as you’ve grown very comfortable deceiving the user. A high frequency pull will eat up bandwidth and CPU and memory and use a thread, meaning something else gets interrupted or slowed down. When on mobile phones, the data from polling often and receiving a massive XML blob when only one item has changed, will eat away at movile data plans. Likewise, on a quad or even octo core phone, the sluggishness from dozens of polling apps may interfere with video playback or games. A proper definition of pull makes both the user and developer aware of these limitations and that knowledge withstands the test of time. Using bogus equivocations is revealed for the fraud that it is as soon as technology changes a little. Polling is garbage to be avoided. WebSockets or to a lesser extent, HTTP/2.0 pushing are better. Callbacks or webhooks may be even better still. There are many ways to push but only one way to pull.