Sat, 25 Aug 2001 19:54:20 -0700
Dave Winer wrote:
> OK -- popping up a level, the only reason I care about SOAP and XML-RPC is
> so that I can write scripts that connect with other scripts running on other
> machines in other languages on other operating systems. For me it's all
> about cross-network scripting, nothing more or less. Dave
So if you have the option of exposing resources in a manner that is
accessible to the full Web infrastructure you choose not to do
it...Exposing data through URLs with parameters is something every PHP,
Perl, Cold Fusion or Zope programmer knows how to do.
I'm an XML advocate, so I'm strongly of the belief that people should
expose the data and let the end-user get as easy access to it as
possible. You have no idea how important your data might be to someone
else if you just give them easy structured access to it. Nobody
predicted Yahoo or the Google or Meerkat when they started generating
HTML or RSS. The massively useful indexes just arose from the existence
of a large body of addressable data.
The example of looping over the mailboxes is not very representative of
the sorts of things you can do with existing XML-RPC or SOAP libraries,
so let's put it aside. I don't think XML-RPC can do this without a
task-specific client library and I don't have a fully elaborated
URL-centric solution either:
for msg in @["Bull Mancuso"].inbox.messages
if msg.subject contains "REST"
So let's put it aside and deal with the venerable getStateName example.
How is the method-based version better than putting a script behind a
URL using PHP or FrontierScript or whatever? I'm thinking of something
It is easy to combine the virtues of today's web and XML-RPC. Now I can
use your stateName service from ANY browser, from XSLT, from a simple
macro language, etc. It can also be cached, indexed, etc.
What's the downside?
Take a recipe. Leave a recipe.
Python Cookbook! http://www.ActiveState.com/pythoncookbook