The Internet is about to change(blogmaverick.com)
blogmaverick.com
The Internet is about to change
http://blogmaverick.com/2009/08/25/the-internet-is-about-to-change/
11 comments
I worked for Pointcast :)
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.
Ah, the good old days of spending $80m...
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.
Ah, the good old days of spending $80m...
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.
Since he actually worked there and experienced what they were doing, wouldn't he be a first-hand source?
It's not enough for Wikipedia. References need to exist in some form of media, so if necessary, readers are able to check them.
Wikipedia Policy: Verifiability http://en.wikipedia.org/wiki/Wikipedia:Verifiability
Wikipedia Policy: Verifiability http://en.wikipedia.org/wiki/Wikipedia:Verifiability
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)
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)
Ugh, this sounds like a very very bad dream.
I loved point cast!
Maybe the idea was just before its time. In the era of the lightweight REST API I think there is a much greater chance of success.
I'm not sure I see the connection between AOL implemented in a screensaver and a new design idiom for web applications.
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.
PointCast is just the poster child for that movement which never really made any big waves.
I guess my point is, "push" meant something different then.
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.
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.
But that is a different discussion altogether...
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.
But that is a different discussion altogether...
> In fact, complications in calculating sales tax cause many businesses to outsource their entire payments to something like PayPal.
How does PayPal address that problem? I don't see anything on the paypal site that concerns tax rates for different items in different jurisdictions.
How does PayPal address that problem? I don't see anything on the paypal site that concerns tax rates for different items in different jurisdictions.
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 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.
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 Joshua Schachter told me something like 40% of hits on delicious return Not Modified. Because of polling.
I'm sorry, maybe my ignorance is showing here, but in the example, aren't they pretty much just describing a cgi?
for example...
example.com/cgi-bin/gettaxes.cgi?state=AZ&longzip=85251&ammount=82521&trans_id=23894
which returns some text?
Am I totally missing the point here?
for example...
example.com/cgi-bin/gettaxes.cgi?state=AZ&longzip=85251&ammount=82521&trans_id=23894
which returns some text?
Am I totally missing the point here?
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.
http://webhooks.pbworks.com/
http://webhooks.pbworks.com/
Still, I don't see how "webhooks" help? Isn't it equivalent to having two webservices, one having a method for registering URLs?
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.
Actually, now that I explain it that way, it doesn't seem that revolutionary. It just makes building neat hacks a tiny bit easier.
I think you just got buzzworded, ;-)...
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".
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.
Correction: the Web is about to change.
The Internet, not so much. The protocols are still pretty much the same.
The Internet, not so much. The protocols are still pretty much the same.
by my knowledge he is atleast weeks if not months late, on the news ... but he does give a "reason to care" - which adds value to the conversation...
- The web.. seems to change, slowly when we think its changing fast and really really fast when it seems boring.
- The web.. seems to change, slowly when we think its changing fast and really really fast when it seems boring.
I think it's great this idea is gaining mindshare. However it seems like most people miss the point... even after me telling them they are.
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...