- From: Michael Condry <Michael.Condry@eng.sun.com>
- Date: Wed, 17 May 2000 09:37:05 -0700
- 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 UTC