'. '


From APIDesign

Revision as of 06:02, 10 June 2009 by JaroslavTulach (Talk | contribs)
Jump to: navigation, search


Close Proximity of API-less APIs

Can you imagine world without an API? I can now. This website is powered by MediaWiki and from time to time I need to improve it to better suite its users needs, to prevent spam, etc. Recently I integrated preview mode for mp3s (so now we really have MediaWiki and not only pictures wiki) and I also integrated Captcha and ReCAPTCHA with the articlecomments extension. Both these experiences made me realize some gotchas related to living in API less world.

Edit the Source

The usual style to work with MediaWiki is to download its release, unzip it and get its sources into some disk folder. Whenever one wants to configure the system or wants to install some extension, one of the necessary steps is to edit some source file. There are some best practices and well-known files that are designed to be edited, however not all tasks can be achieved by sticking to these files. As far as I can tell in order to change skin (to white on black which few people love and many hate) one has to cross the rubicon and edit files that are not in so well-known.

I am trying to express two claims:

  1. editing sources is essential part of using the API of MediaWiki
  2. there is no enforced boundary between the well-known files and the less known ones

As a result what starts as expected use of the API - e.g. editing local settings configuration file, may soon grow beyond anything expected by the MediaWiki developers. This is inevitable, there is no sharp boundary and just a minimal warning to notify you about crossing a dangerous boundary.

Fear of Upgrades

nobody upgrades running servers

diff backward compatibility

Consultant story

sell a consultant per copy, like R.?

Need API on server?

not as a producer, but yes as a consumer. or being stuck with one version

Personal tools