W3C home > Mailing lists > Public > xml-dist-app@w3.org > May 2000

Re: Web RPCs Considered Harmful

From: Michael Condry <Michael.Condry@eng.sun.com>
Date: Wed, 17 May 2000 09:37:05 -0700
Message-Id: <200005170735.e4H7Z6h208019@jurassic.eng.sun.com>
To: "Ken MacLeod" <ken@bitsko.slc.ut.us>, <xml-dist-app@w3.org>
Some APIs are not developed in an open manner because they
are committed to a single architecture.

>Edd Dumbill <edd@usefulinc.com> writes:
>
>> Although you point out that data transfer protocols have the
>> opportunity of avoiding lock-in, I'm not sure it's an API vs data
>> transfer thing.  I can't see that it's any more difficult to
>> obfuscate a data format than an API.
>
>Yes, this is true for intentional lock-in and is already a well-known
>issue with XML, for example.
>
>For whatever social or political reasons, data formats seem to be
>developed and presented in a very open manner whereas APIs seem to be
>developed in isolation and then published, as Wes points out in his
>reply.  The problem here is _unintentional_ lock-in and fragmentation.
>If APIs were developed as openly as data formats, this would be a much
>smaller issue.
>
>As someone recently pointed out to me, designs tend to lead towards
>uses.  If you design something that encourages openness (like XML)
>you'll get it whereas if you design something that doesn't encourage
>openness (like RPCs for APIs) you won't get it.
>
>> One thing that I've not worked out yet--and which would be
>> instructive to do in order to further understand the issues--is the
>> flow of money in the brave new world of web APIs. What
>> products/services will be offered, to whom, and at what cost? That
>> will dictate as much as anything the level of openness. If nobody
>> can make money by being open then...
>
>Right now, the money is in the past investment and current momentum of
>RPCs, and will likely continue flowing that way for a while.
>Hopefully presentation of practical alternatives will start flowing
>money in that direction and will eventually resolve the issue.
>
>  -- Ken
>
Received on Wednesday, 17 May 2000 03:35:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:56 GMT