On 27/11/2007, Dave Crossland <[EMAIL PROTECTED]> wrote: > > On 27/11/2007, Brian Butterworth <[EMAIL PROTECTED]> wrote: > > > > > > Sure, and I'm suggesting that a common API will be a base that each > > > gatekeeper will add bespoke features too. I'll be surprised if similar > > > services offered with a "common open API" from Google and Yahoo and > > > Microsoft do not have any specialist features to differentiate them. > > > > Does the track record of Microsoft not show that they created aparent > APIs > > and then did not use them themselves? > > Right - this is the problem with saying "Oh, I _could_ download the > source code that runs this API interface, but actually I'm not going > to bother and just use the service provided." - there is no guarantee > that what you can download is what is running on their server.
Indeed, this is quite an important considertion in the anti-trust actions that the EU has been persuing Microsoft about. I'm lumping Google, Yahoo and Microsoft together as all equivalently > bad - along with all smaller "Web 2.0" API providers who provide > computation services through web APIs, making a subtle distinction > between those servces and those that are data request protocols more > sophsticated than HTTP. There would be no problem if these APIs were published and were not broken for competative advantage? "Use our stuff to make your stuff," to me, refers to providing BBC > data for the British public to do computation with, and where > Backstage publishes APIs that take input data, transform that data, > and return the result, the source code for the transformations ought > to be published as free software - preferably under the GNU Affero > GPLv3 or some other network-aware copyleft license. Not sure about "ought", other than the grounds that the BBC is a publiclly funded body. > > > > Freedom means more than a choice of lords. > > > > > > > > You can happily run your own things and then be your own lord, > > > > > > ...but not if the gatekeepers continue to offer software to the public > > > without making the source code to that software public. > > > > To be fair, I think that there is an important point missing here. > > > > A closed API is fine if the service is best run somewhere remote. > > Well, if Google is searching _their_ data - their copy of the web, say > - and returning the results to you, that's good. Its their copy, > afterall. OK. I see your point - very funny! But if you upload your data - say, your spreadsheet numbers and > equations - and get them to do your computation for you, instead of > using Gnumeric or OpenOffice, that's not good. I agree that there are problems with keeping your data in the network. He types into Gmail. > For > > example, if I need to use a database engine, I'm really bothered about > how > > well the API supports my SQL statements, not how they are executed. > > Right - because SQL is a "query language" for requesting data to be > sent to you, for you to do your own computation on. And HTTP is also a "query langage" as is SMTP and so on. Also I can use SQL on other people's data, the security sometimes only allows me to SELECT. This, I note, is the problem that Revenue and Customs had. > On the other hand, software that is transferred onto my own machine, I > care > > more about. I seem to have a concept of personal rights that extends to > my > > computer's CPU. If the code is in my machine, I should be able to know > how > > it works, if I so choose. > > Right > > > It's a strange concept though. The logic of the argument is that I > could, > > if I had the time, work out how it all works from the assembler code. > > http://en.wikipedia.org/wiki/Reductio_ad_absurdum Perhaps. But I have done it. I recall there was a BBC Micro program called "Peeko computer" that did it quite well. I've written the odd disassembler too... > If it > > can be run on my computer, then it has to be in a published > format. CPUs > > can't be "closed" because if the manufacturer refused to let you know > the > > instruction set, they wouldn't sell that many. > > > > But is that an API? Where is the boundary between CPU and APIs? > > Source code. What about the source code of the CPU's microcode? > At the other level (and bringing it back to backstage) what about the well > > known API of RSS? Should I care how the RSS feed is created? > > Does the RSS feed contain the BBCs news? Or does it contain your data > that has been transformed in some way? I use both, but iGoogle doesn't care. -- > Regards, > Dave > - > Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please > visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. > Unofficial > list archive: http://www.mail-archive.com/[email protected]/ > -- Please email me back if you need any more help. Brian Butterworth http://www.ukfree.tv
