I had an idea that would be nice to have implemented to the editing api when it's done. The idea is to have some sort of transactions (dunno if it's the right word), so that multiple edits are done only if them all are possible. For example, if a program is to edit four pages, lets say to nominate a page for deletion, thus first create a nomination page, then link that page to the todays list, then add a template to the actual page, and lastly notify the OP. All those edits should only be done if them all can be done. With this functionality should be an option to disable merge, and thus not make the edit if an merge would be needed (to prevent two people to do almost the same thing).
How to manage to do this could be difficult. one way would be to be able to send multiple edit requests in one API call, but as the query syntax (foo=bar&baz=quux) doesn't really support that (you would have to index them then), a solution could be to allow queries using xml instead.
An other more problematic implementation would be to have a meta call to start and stop transactions. But that would raise the question how long would the server keep a request in memory until discarded, i.e. how long would it allow a client to wait sending the completion call.
Perhaps this is difficult to implement, as it would require multiple edits to be performed as one atom, but it would be greatly to reduce errors when failing to edit one of many required pages, as the example above tells.
I have been considering a batch request implementation - where more than one query/post requests can be joined into a single call. I am not sure it is still needed as query allows multiple item retrieval already (prop=links|langlinks) for multiple pages (titles=a|b|c). Multiple page post requests might be useful, but would be implemented much later - we really ought to get the basic features working first :)
On 8/28/07, Carl Fürstenberg azatoth@gmail.com wrote:
I had an idea that would be nice to have implemented to the editing api when it's done. The idea is to have some sort of transactions (dunno if it's the right word), so that multiple edits are done only if them all are possible. For example, if a program is to edit four pages, lets say to nominate a page for deletion, thus first create a nomination page, then link that page to the todays list, then add a template to the actual page, and lastly notify the OP. All those edits should only be done if them all can be done. With this functionality should be an option to disable merge, and thus not make the edit if an merge would be needed (to prevent two people to do almost the same thing).
How to manage to do this could be difficult. one way would be to be able to send multiple edit requests in one API call, but as the query syntax (foo=bar&baz=quux) doesn't really support that (you would have to index them then), a solution could be to allow queries using xml instead.
An other more problematic implementation would be to have a meta call to start and stop transactions. But that would raise the question how long would the server keep a request in memory until discarded, i.e. how long would it allow a client to wait sending the completion call.
Perhaps this is difficult to implement, as it would require multiple edits to be performed as one atom, but it would be greatly to reduce errors when failing to edit one of many required pages, as the example above tells.
-- /Carl Fürstenberg azatoth@gmail.com _______________________________________________ Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-api
On 8/28/07, Yuri Astrakhan yuriastrakhan@gmail.com wrote:
I have been considering a batch request implementation - where more than one query/post requests can be joined into a single call. I am not sure it is still needed as query allows multiple item retrieval already (prop=links|langlinks) for multiple pages (titles=a|b|c). Multiple page post requests might be useful, but would be implemented much later - we really ought to get the basic features working first :)
Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-api
Yea, and on the basic features, hows the progress?
mediawiki-api@lists.wikimedia.org