It's hard for me to believe that push technology is going to revolutionize the internet. Why? Because it didn't happen last time (or the time before that).
The PointCast Network used push technology, which
was a hot concept at the time, and received enormous
press coverage when it launched in beta form on
February 13, 1996.
Since the early days of the web, people have recognized that the pull model has serious limitations. Unfortunately, pushing data to users has never been compelling enough to spark anything that qualifies as a revolution. People really want data to be pushed to them if that data is intended specifically for them (e.g. email and IM), but not if it's general weather and news data.
I do love Cuban's honesty, though:
Would NY Times online readers pay $1 a month to be
guaranteed that they get their news first, before
anyone else? I dont know.
Most people would claim to be able to predict the future in order to make their point. He doesn't.
EDIT: I should add that his idea that "Huge databases can talk to huge databases and exchange data more efficiently" is cool and makes much more sense than pushing data to users. We're actually working on something along those lines right now...
The data was specifically for the individual, you could customize the data you were pushed using the client. It wasn't just a screensaver.
That wikipedia pages misses a lot of the fun back then. Dave Dorman was a really bad choice of CEO, he didn't even have a computer and his first priority seemed to be picking the type of Walnut to have his personal carpenter make his desk from.
As a Wikipedia admin, I'd love to have you update the article for Pointcast, especially if you have sources you can reference while filling in the gaps & correcting information.
Very cool! It must have been fun to watch that all play out first hand. I was in High School still, unfortunately. I was definitely a PointCast user, though. Although it didn't turn out to be revolutionary, I certainly found it useful.
It was fun, except, had the board (Chris mostly) accepted the offer of $450m then I would not have had to work any longer. Alas. I also turned down an offer to join Nutscrape way back too. All fabulous examples of great career choices I've made...
The thing that probably had the biggest negative impact was rewriting the client in COM (who remembers that?), this gave us absolutely no new features and bogged down client development for six months, meanwhile portals became the new hotness.
There were some interesting developer issues that we tackled back then, like using the i/o completion ports model (rather than the more traditional BSD sockets model). Since the servers were all NT the i/o completion ports made the code hard to debug but resulted in very high performance. I think (if memory serves) MSFT got that from their VMS roots. Some of the kernel guys on NT were bigshots at DEC (http://en.wikipedia.org/wiki/File:Vax780_small.jpeg)
Many of us probably don't remember these early days of the web, but a lot of companies were founded (and acquired) because they were going to be part of the impending "push technology" revolution.
PointCast is just the poster child for that movement which never really made any big waves.
One of the great things about the internet is it's always about to change.
I think these services have interesting models....but I'll be damned if I'm going to let a 'sales tax calculator' blow a sale because it goes down. A rational business cannot rely on services they can't, at least in some small way, control.
In fact, complications in calculating sales tax cause many businesses to outsource their entire payments to something like PayPal. If instead they had a number of competing sales tax calculators and other services, one can imagine a payment platform built on a loose network of services with the ability to failover when one goes down.
Exactly. It would seem that one of the biggest problems facing the Internet and the growing dependence on Internet based services/applications is the fact that you are often fully dependent on (and at the mercy of) a single fallible system.
If our next generation of web services/applications relied on (is designed to be) a "cloud" based system, capable of dynamically switching between the multiple available services of a specific type, your users could rely on your service, regardless of what a single given service's stability or status is - one goes down, another one picks up. *trivial example: Think Twitter outages - if there was instead a redundant vanilla twitter-like messaging system, outages would not impact usability of its applications...
This said, I cannot help but wonder about the fiscal reality of such a infrastructure. In 'narrowing the delivered content more specifically to match the actual desired data' and 'its delivery mechanism' being hammered out, I can't help but wonder about the 'pay off'? Where is the mechanism that allows "content owners" to 'brand' and/or capitalize on "their" data.
Rational businesses also have to decide what work to outsource and what work to do internally. If there was a reliable provider of this service, I think many businesses would outsource it.
True, but decoupling services via HTTP just makes the fault lines more explicit. I imagine more of these services (like many of the current webhooks stuff Jeff Lindsay is putting out) will be opensource and easily adapted to virtual appliances / dedicated hosting. That way you can choose exactly when hosted vs hosting it yourself makes more sense.
This technology has been around for a long time. It's fundamental to PayPal IPN, their payment notification system.
I also thought it was funny that he said websites constantly monitor the url for POSTs. I imagine a web server in an infinite loop, "Did someone post? Did someone post? Did someone post?"
I don't see anyone commenting on the amount of bandwidth this will free up though.
Instead of someone's RSS Client polling 30 websites every 15 minutes, you have a single 'hub' that gets pushed data once (the hub doesn't even have to poll). This is not to mention all of those blog sidebar feeds that display things like flickr/delicious/twitter/etc.
On the other hand, this might screw up 'reader statistics' depending on how it's implemented.
I think his explanation is just wrong. My understanding is that the web app says, "Hey, if you give us a URL, we'll POST (or GET, PUT, etc) these parameters to it whenever a certain event happens." On your machine, you just set up a script at the URL. Then whenever someone you follow on Twitter tweets, for example, Twitter will POST user=blhack&tweet=My%20spoon%20is%20too%20big to the URL you gave them. That effectively gives you a push API instead of the conventional pull APIs.
You do have two web services. If you wanted to implement what I described today, you'd have to periodically poll Twitter's API or RSS feed for data. With web hooks, there's no more polling. Twitter calls your web service when there's new data.
Actually, now that I explain it that way, it doesn't seem that revolutionary. It just makes building neat hacks a tiny bit easier.
It sounds like this magical "push" thing already exists. It is called "get" and "post".
For example, my website is a stupid news aggregator (http://www.gibsonandlily.com). If a story gets more than ~30 points (which is really rare since there are only a few people that post there), it calls up tinyurl and says:
"Hey...tinurl, if you wouldn't mind, could you please give me a tinyurl of this link so that I can post it to twitter?"
Tinurl responds
"Hey, I'M TOO BUY POSTING TO TECHCRUNCH, GO AWAY!"
To which my server says
"But c'mon, tinurl...pleaaaseeee????"
Tinurl:
"Fine, here, no go AWAY! Also, aren't I frigging revolutionary?!"
Then it calls up twitter and says
"Hey, uhm...brah, like zomfg wutcha doin? Check out this uber link!"
and twtitter posts it.
This isn't some revolutionary "push" feature, this is just standard cgi action.
It sounds like this is the same thing, just in reverse...which really isn't that "revolutionary", more like "duh".
What you're describing is a pull, so yes, a push would be that in reverse. Polling is inconvenient. Web hooks aren't "revolutionary", but they're still cool.
Everyday the biggest databases on the internet talk to each other. Did someone forget about DNS ? I enjoy the 2.0 apps and technologies being developed, some are being called disrupted others revolutionary, If you weren't around 1.0 I can see how that's possible. PubSub looks like it could help make communication between apps/server less complicated, not a changer.
I think I'm on the outside and ignorant of this, but I don't get it. Of course I'm very used to working with subscribing to events in javascript and this sounds similar conceptually. However, I don't grok what the advantages are between urls.
From http://en.wikipedia.org/wiki/PointCast_(dotcom):
Since the early days of the web, people have recognized that the pull model has serious limitations. Unfortunately, pushing data to users has never been compelling enough to spark anything that qualifies as a revolution. People really want data to be pushed to them if that data is intended specifically for them (e.g. email and IM), but not if it's general weather and news data.I do love Cuban's honesty, though:
Most people would claim to be able to predict the future in order to make their point. He doesn't.EDIT: I should add that his idea that "Huge databases can talk to huge databases and exchange data more efficiently" is cool and makes much more sense than pushing data to users. We're actually working on something along those lines right now...