Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: ANN: REST Tutorial
 Then one has to ask, how much cost can be absorbed and opportunities deferred while waiting for a standard or specification process to settle down. Again, what makes RPC communications attractive is the "immediateness" of implementation. What is it the everyone understands or think they understand that can be applied to the immediate problems of fielding systems? REST is only a piece of a solution. What is the next step? Big schemas? Small schemas? No schemas? Whose schemas? In what order should we solve the problems? HTML only solved one problem. It was the problem everyone had: a downtranslation target for a weak but serviceable rendering on a screen at low to medium resolutions. The success was not due to most of the reasons given, but that *it solved a problem everyone had*. Then low costs made it not only a neat solution but a compelling one. The dilemma of the document-centric or data-centric standard schema design is waiting for it to be complete and knowing by dint of experience, that every day it is in draft form, it is accreting features. Those of us who sat through CALS watched the 38784 originated document spec turn into the over 1000 page 28001 DTD spec driven by black projects whose experience base was also opaque, therefore, whose implementations were also opaque. We went from a document description that most experienced writers understood and managers knew how to customize (it solved a problem everyone had) to a mass of technical obscurity that was expensive to digest and understand and for which all of the toolsets were experiments escaping the lab (it solved lots of problems only a few people had). There was a middle point where it was easier to digest 28001 and it all gelled, but that didn't last long because it became the only "legitimate SGML DTD" for mil work and it was a print system stalled out over the FOSI and DSSSL. While some progress was made in databased IETMs for digital display, the print system got the attention, the money, and every feature imaginable. Innovation was pushed like a round peg into an octagonal hole. Big iron moved the monster. The dot.bomb was public. The CALS fiascos were DoD line items. Most of you didn't get to see four billion disappear into the consultancy and LargeSystemIntegrator pocketbooks. Did it work? Yes. Did it thrive? No. Who got the benefits? Mostly very big concerns. It paid salaries and educated a core absorbed eventually into the web where small was beautiful and those absorbed were eager to get small. Drift. Big schemas drift worse than small local interfaces. SOAP RPC has the quality of immediateness that the working programmer understands. Universal access, uniform identity, these are neat for Yahoo and CNN, but they don't mean a thing to a project whose total scope is a handful of qualified systems. They are in fact, counterproductive. An RPC interface is a simple thing compared to learning how to process a complex schema driven document. And it drifts less often. I see the arguments about "what if the interface changes"; well, what if the schema changes? Same problem; bigger scope with larger impact on local systems. len From: Matt Gushee [mailto:mgushee@h...] On Tue, May 21, 2002 at 10:36:14AM -0500, Bullard, Claude L (Len) wrote: > Errrr.... yes and no. The REST model of communication > isn't as familiar to mainstream programmers as one > might assume. You're right. My statement was an oversimplification. When I said 'near-universal presence', I meant that everybody's got the Web. Whether they understand it in what many of us consider the 'proper' way is another matter, as you rightly point out. 
|
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
|
|||||||||
