[
Lists Home |
Date Index |
Thread Index
]
From: Paul Prescod [mailto:paul@prescod.net]
>100 people can run in the wrong way and I still won't follow them.
I'm not asking you to. I'm saying, it ain't just MS running in
that direction. So flaming in their direction just wastes coal.
>I think it is incorrect to say that SOAP is an architecture. SOAP is a
>syntax that can be adapted to a variety of architectures.
That's an interesting point. XML is a syntax too. That seems to be
a successful place to start.
>The interoperable variant of SOAP uses an RPC architecture and even most
>backers of SOAP agree that this is not where it will end up. They
>haven't articulated where it will end up but they are clear that it is
>not RPC.
Ok. So if the RPC is an interim step, then articulating the next one
would be the most useful way to steer the debate. I think that is
what you and Tim et al are doing. Dave, what would be the next step
for SOAP?
Still, if SOAP RPC is on the auction block,
why is so much attention being paid to it? Because it is a familiar
way to program and efficient. It allows a lot of local control at
the expense of making those controls understandable to interested
qualified observers (cost of API maintenance and publishing). The
Internet has room for it and it may just be an evolutionary dead end.
That's life in the ecotones; hot and fast change. On the other hand,
is the issue that it might thrive like kudzu and choke out better
crops? (For those who never visited the American south: kudzu
was not native here. It was brought in to control soil erosion.
Then it thrived and took over any ground not otherwise plowed
seasonally. The same bright types put alligators in the wildlife
refuges locally to keep the beaver population down because they
kept building dams across waterways. Now fishermen carry rifles
when they fish. And so it goes. Ecosystem management is dirty
business if the results obtained have side effects.)
>Nevertheless, I have trouble understanding how your article relates to
>any of the following documents: a) my original Google article, b) Dave's
>rebuttal, c) my counter.
That isn't my point. My point is that these two approaches can
exist side by side and it is the buyer that must beware. Otherwise,
much fury here and not much progress except where the technical
points are being illuminated. That you are doing brilliantly.
>If you've reviewed all three articles do you agree or disagree that 1)
>there are substantive technical issues raised 2) Google could have
>chosen a better technology for their API and 3) they should now correct
>their mistake by *at the least* adding a URI-based mechanism for
>retrieving query results?
Google has provided a useful testbed to the SOAP implementors. I think
one should let them explore it and then find out for themselves how
substantial the technical issues are. As you have said, the URI
based mechanisms are ubiquitous so no one has to look far to find
a test case for that.
len
|
