[
Lists Home |
Date Index |
Thread Index
]
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@havenrock.com]
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.
|
