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