I don't have any issues with how my comments were reported, but just for thoroughness' sake, this is the unedited version of what I said. If nothing else, it will give credit where it is due for the zippy quote at the end of the article...
I'm not sure that the API, per se, will do much. It's got a pretty high hack-value and gee-whiz factor...
Notwithstanding the fact that the search widget combined with the
cache widget will return non-HTML documents, you sort of have to ask yourself : why wouldn't I search for web documents in a web browser?
On the other hand, it will probably give a big push towards making
people more familiar and comfortable building sites/tools using
distributed widgets.
See also : http://use.perl.org/~gnat/journal/4163
When asked to elaborate on that last bit :
It's sort of the same idea as the one that the "internet operating
system" gang like to trumpet. For example, pulling in remote content
or manipulating your own content via a remote function as a page
(let's just imagine we're talking about the web) is being published [1].
You can sort of see this happening with the many publish/subscribe
widgets that are popping up [2]. That is, there is a growing
interconnectedness among pages, sites, applications.
I'm not sure I buy it, though. It's plenty cool but there are lots
of problems that need to be worked out. All the same problems that
plague popular websites (bandwidth, scaling, etc.) are going to plague
popular web services and not everyone has a thousand servers like Google does[3].
Not to mention issues of reliability and the nagging sense that I
think a lot of people have that it's just the carrot (cool-ness!)
before the stick (micro-payments!)
Mostly I was just trying to say that being able to "plug"
Google-ness in to your website will, if nothing else, provide an
example of "distributed computing" that is not as abstract as those that have come before it.