Ivan Krstic wrote:
Timwi wrote:
You can start off with some basic functions (retrieve an article, edit an article, retrieve article history) and later move on to more complex ones.
I like the sound of this, but I'm probably biased because I'm really keen on writing it!
The API will be used by programs, not people. People can quickly adapt to changes in the UI, but every mistake that ends up in the API will probably become an incredible PITA that will need to be supported for some time going forward.
I have to admit that this is a very good point, I think an API is something that can be difficult to change once it's written because by definition once it's out there other programs will rely on it staying the same. Getting it right the first time is better than trying to retain backwards compatibility with a badly designed sytem. Writing an API is a big responsibility, especially if it ever gets used with something as hugely significant as Wikipedia.
However...
I thought about this some more yesterday, and I've changed my mind. A first pass at a *very* simple API, if done with care, might actually help frame later API discussions, such as the one at Hacking Days.
Yes, I would argue that going ahead and writing a first cut API before the lengthy process of creating a final and stable specification does have an enormous amount of value. Firstly, it gets the ball rolling and gives people something to play with rather than just talk about. But more than that, by actually trying to write it we could learn an awful lot about what needs to go in that final, stable spec. People might try out the prototype API and come back with some useful feedback about how the API could be improved, before the final spec is set in stone. More than merely possible, in my opinion this may actually be a wise thing to do, especially as the final API is likely to stick around for a long time!
I propose brief community discussion and consultation with the people involved in the current clients with a view to writing a quick interim specification. Based on this specification an initial attempt could be started so there is at least some code in repositories somewhere by the time the hacking sessions at Wikimania come around. This initial API could be released as a "beta" system, with no guarantee of supporting it in the future and a disclaimer making it clear that it is an experimental system only.
This beta system should be carefully designed as if it were going to be the final system, the ideal situation would be that it would not need many changes to meet the final specification. Worst case scenario it would have to be largely re-written or even thrown away. That doesn't mean that writing it wasn't enormously worth while.
I suppose this is modern Agile Programming or rapid prototype type thinking, get coding quickly and develop the design in parallel to the development. It sounds counter-intuitive but there's a large amount of evidence to suggest it works better for programming than more traditional engineering methods for tangible systems. It's also something I've tried out this year with a 2 1/2 month University project and it went well.
In my opinion and conveniently for my application ;), I think stating from the start that this code may not ever be officially supported actually makes the Client API a brilliant project for Google Summer of code!
I wouldn't want to work on any project if there was any community resistance to the work, that would be completely counter-productive in an Open Source type environment.
What do people think?
Best Wishes
Ben
-- Ben "tola" Francis http://hippygeek.co.uk