Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] commodity web
 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
