[
Lists Home |
Date Index |
Thread Index
]
4/20/2002 10:21:30 AM, "Didier PH Martin" <martind@netfolder.com> wrote:
>. For them, seeing Google as a component is a natural
>extension of their actual view of the world. They simply have to drag and
>drop a component on their form and voila, they are now ready to glue it with
>other components.
Ah-ha, I think that's what I've been missing here! Never having used VB, etc.,
I just didn't grok why people would want to jump through hoops to avoid dealing
with a very simple URI/HTTP call/XML result. That just doesn't fit into the
"paradigm" of visual component assembly programming, but WSDL/SOAP-RPC does.
And the "hoops" are hidden out of sight, along with all the other code generation
that VB is doing.
>
>So, Google simply gave an answer based on sound marketing principles. The
>main market is using procedural tools. This has noting to do with XML and we
>would be lured to think the contrary.
Right! This helps crystallize another issue that has been bugging me: is there
any intrinsic reason why "functional" or "REST-like" (I'm not sure they're the
same, but that's another issue) development can't be done in a VB-friendly way?
I'm bewildered by this stuff partly because Microsoft, Macromedia, have
made lots of progress in the last 5 years making web PAGE development accessible
to non-nerds, and it seemed logical that this technology could be leveraged
to make RESTful web SERVICE development accessible to non-nerds. Or maybe the
people who understand "procedural" aspects of website development have been
behind the scenes all along, and gravitate toward SOAP-RPC because it simply
eliminates all the HTML/HTTP stuff between the producer and consumer of
a web page/service?
It looks like Paul Prescod's site http://www.prescod.net/rest/googleapi.html
and some comments to the WS-Description mailing list are the kinds of things
that the REST advocates need to do: make REST WSDL-friendly (or WSDL REST-friendly)
so that end-users can easily choose (or have their tool choose) the right
architecture for the job at hand rather than insisting on RPC Everywhere.
That misses the point that Didier was making -- that people really SHOULD
understand the technology to use it effectively -- but is good PR.
|
