Rich Morin wrote: I agree with this. 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. Each of these functions is largely independent of each other, and inconsistencies between them do not make the whole API fail.

I was wondering how it could be possible to make a real AJAX user interface without having a strong API. I've seen another SoC proposition about AJAX. Including 2 or 3 ajax tools seems to be just a step, that would be thrown away after having built a fully ajax-made interface. Is it too early for that too ? Plyd On 4/27/06, Ivan Krstic <krstic(a)fas.harvard.edu> wrote:

there are several tools that could be interesting to have in AJAX, the editing preview, but I have several other examples that could be faster for the user : - following or not a page without having to reload a new page - the [edit] button that opens a box directly inside the page without reloading another one - renaming/deleting etc. in the same way (box added at the top of the page) These tools are far from necessary but they improve the use of MediaWiki and they could reduce the number of requests for the servers. I have also in mind a new SpecialRC.php page, in ajax too. It would be updated automatically and would offer instant tools, like viewing beginning of the diff passing just the mouse on the link, sending messages to an IP or a new user directly from the RC page, ... and helping stuff to fight vandalism. (A tool that would finally turn the RC page into a Vandal Fighter tool, with all the advantages of being included in the browser.) Plyd On 4/27/06, Ivan Krstic <krstic(a)fas.harvard.edu> wrote:

Ivan Krstic wrote: I like the sound of this, but I'm probably biased because I'm really keen on writing it! 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... 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

Well, I've been kind of thinking on the following lines: Each MediaWiki wiki administrator - in the case of Wikipedia that would be Wikimedia - can monitor what API calls are still regularly used. It's not really something like HTML where you want backwards compatibility because you don't know how many millions of unmaintained old documents still exist and still want to be read. We do. We can tell if the usage level of an old API function has dropped below a certain threshold, at which case we can decide to stop supporting it. Although we will end up requiring some tool developers to use the new API and some users of unmaintained tools to use other tools, we can be sure that it won't be many. Hence I don't think backwards compatibility is going to be a huge long-term requirement for us. Timwi

Brion, You have removed the Client API entry from the Summer of Code page on the wiki with a comment "Removing this since a number of people are actively working on such already". Who are the number of people who are actively working on this and does this wiki change signify that the Client API project is officially no longer open for applications through Summer of Code? Bearing in mind applications open today. Yours disappointedly, Ben -- Ben "tola" Francis http://hippygeek.co.uk

Yuri Astrakhan wrote: It's certainly valuable, but I don't think it fits within the Summer of Code framework, which requires the students to do their own work rather than collaborating in groups with the outside. -- brion vibber (brion @ pobox.com)

On 02/05/06, Ben Francis <lists(a)hippygeek.co.uk> wrote: Yes, there are people working on it. No, it's not a suitable SoC project. The rationale for this, I think, is that the API, similar to the formalised parser stuff, is the sort of thing which requires a lot of discussion and collaboration between advanced users, developers, extension writers, etc. and isn't suitable for the sort of working environment where a student codes most of it without much interaction, save for his/her mentor. Rob Church