> Not to belabor a long-running disagreement, but this is the essence of
> where we part company. I would instead say:
Agreed. We're rehashing old arguments. I'll try to refrain from
responding with old answers.
> "where we take care to use HTTP in a manner appropriate to the
> message"
>
> First the message exists, per the SOAP rules (I.e. there is an Infoset
> before we even talk about what transport to use.) Then, we can decide
> whether HTTP is an appropriate vehicle for moving this sort of message
> (maybe it has GET semantics and we don't have a GET binding, so we don't
> use HTTP).
I strongly disagree. You can't flip application protocols in and out
like transport protocols with different qualities of service. The
application protocol defines the semantics of the task that you're
trying to accomplish; the reason why somebody would choose to use your
software, versus some other software. When you sit down to write code,
you must necessarily have a well defined task in mind. This task is the
application, and application protocols specify application semantics
for these tasks over a network.
If you wanted to write a distributed stock quote app, one way or
another you need application semantics. Protocol weenies, such as
myself, would do it with an "on-the-wire" request that might look like
this;
GET-QUOTE stock:sunw
Desired-Freshness: 2mins
with response codes corresponding to "unknown symbol", "unmatched
freshness", etc..
An API weenie might do this with an API over an RPC protocol;
interface StockQuote
{
string getQuote( string symbol, string[] modifiers)
throws UnknownSymbol, UnmatchedFreshness
}
But no matter how you implement it, "get quote", "unknown symbol", etc.
are your application semantics, and I assume that you wouldn't try to
write code that retrieved weather reports with these application
semantics, right?
MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker@planetfred.comhttp://www.markbaker.cahttp://www.planetfred.com