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 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.
Too much of MediaWiki has traditionally been plagued by the "just sit
down and spit out some code" approach to development, which led to an
unseemly growth by agglomeration, and a codebase that's only recently
been getting less horrid. Given the context -- volunteer coders,
non-profit organization, etc -- some code is better than no code, so I'm
not passing judgment here. But given a tangible opportunity to get a
serious component like the API right (for some value of 'right' that's
more than what one would obtain just by sitting down and hacking),
waiting another couple of months to get everyone in a room and hash this
out seems to be by far the best approach.
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. So I'd still discourage the API being a SoC
project. Of course, I'm not affiliated with the Foundation, so Ben is
more than welcome to still submit his application for it.
Ivan Krstic <krstic(a)fas.harvard.edu> | GPG: 0x147C722D