[
Lists Home |
Date Index |
Thread Index
]
Paul Prescod:
"On the other hand, both XML and HTTP are generalized enough that they
cover a vast tract of the application space. XML covers all labelled
trees. HTTP covers all manipulation (GETting, PUTting and extending) of
named resources."
I don't believe the REST/HTTP/Services (and occasional patent)
discussions that are cropping up here are technologically grounded.
They're symptomatic of the economics of building "web software", which I
hold will more and mean building "software".
Mark Baker:
"getFile(), getName(), getArticle(), getStockQuote() were what we had
*before* the Web. I can't see any reason to go back after
seeing what can be achieved with GET."
There is value here, but this notion of verb generalisation (or if you
prefer, deep structure for messages) has been around in programming
languages and philosophy for a long long time in web years; JL Austin,
John Searle, Alonzo Church, Noam Chomsky, John McCarthy have all worked
on this in one way or another. We'd do well to know our history; the
issue here isn't technical, it's to do with making machines sociable.
Now we have GET(Name), GET(File), GET(StockQuote) where Name, File,
StockQuote don't clash. And will we have INVOKE(VERB, NOUN) someday?
Maybe; certainly HTTP isn't well enough defined for us to start cross
pollinating its core verbs. Extensibility and rough consensus can bring
fragmentation; witness what happened with KQML and what FIPA-ACL learned
from it re verbs. In active languages, verbs come and go at a slower
rate than nouns; shared understanding of verbs counts for more than
nouns.
The URI also has an important cross protocol role to play. URIs are a
clever way to implement a global file system, they might yet be good
enough for naming. URIs have a social downside however; to be a network
distributor, pragmatically you have to pay for a URI root, whereas you
don't have to pay for HTTP. Not much maybe, for now, but there is a toll
to be had. I imagine that web architects consider URIs to be more
fundamental than wire and application protocols; they'd do well to
consider how to bring them or their successors closer to the commons.
All issues worth talking about re URIs are social/economic in nature.
Gavin Nichol:
"So the *real* question isn't whether we should use REST principals, or
HTTP, or BEEP, or <whatever>. It's "what is the problem being solved"
first and foremost."
Great question. The problem being solved is industrialization. The web
is an interesting social phenomenon, further it is a huge social
phenomenon within the software industry, but it is not a new
technological phenomenon, as most of us know. What makes HTTP excellent
is what makes XML excellent, and it is not in their standing as software
engineering, rather, it's their value as social engineering. Drive
serialisation software down to commodity status via standardisation of
grammars or protocols. Increase interoperability. Reduce economic
leverages. Open up economies of scale. Calling this phase of the web,
web services, is a bit of a joke. Services are what an economy produces
when industrialized means of production are in place. We're not even
close to that, but commoditizing network plumbing is a good start.
Wedgwood thought of using a factory and made a good go of it, but Colt
and Ford made factories that changed the world. In this light, the hype
induced by the web, then XML, then web services in non-software circles
is fully understandable. After nearly five decades of shoddy wares and
false hopes, people think, maybe this time, we're finally
industrializing software. One thing saving the software industry from
near immediate rationalisation is the fact that material (re-production)
costs are tiny compared to most other goods and the absurd maintenance
costs induced by non-standard non-compatible code are typically
offloaded to the buyer; both these can be offset against high costs
associated with the skilled workmanship required to produce code. If we
weren't able to make users pay for maintenance, service packs and
patches, or had to pay through the nose on materials, we'd make good on
standards in a heartbeat, simply because like the guilds of old, there
isn't enough skill to go around.
That in itself is hardly a new idea either. But the adoption of HTTP and
XML and SOAP are important *acts*, because there is far too much
resistance to commoditization in software, despite all the standards
posturing that surrounds the web. In the future, we'll only need a few
people to make our software nuts and bolts and their margins will always
be tight. The economics of software don't really add up and that has a
lot to do with the fact that we build bespoke again and again.
Hype is what you call a market demand you don't think you can serve.
Some vendors will try to put a spanner in the works and maintain
leverage and lock-in despite the consequences of these standards. They
may succeed in the short term. But eventually, markets are served.
Bill de hÓra
|
