On 5/4/06, Erik Moeller eloquence@gmail.com wrote:
Make sure you test how the app reacts in case of edit conflicts, I'm not sure the current script handles them properly. Also check the caching behavior. The current script may view out of date images, for instance, after saving (it sometimes does, sometimes doesn't, probably a race condition). A MediaWiki URL that ends with &action=purge should override all caching.
ok so before uploading a modified file back to the server I could do a &action=purge and check the diff.
It might also be nice to have an additional method of saving to the server, simply by saving the file itself from the application. To do this, you would have to monitor changes to the data. This should be optional and quick to enable/disable from the UI (hotkey or visible checkbox).
great idea, I'm going to add it to the todo list :)
Since the helper application will have to be capable of uploading files, adding some additional MediaWiki upload functionality would be a nice way to make the project a little larger. This would be an interesting alternative to your other SoC application for improving the upload process. There are currently a few batch upload utilities, but the only cross-platform tool I've seen is written in Java and rather slow.
you mean a full upload form with the choice of category and all? a Qt/C++ version of the wikimedia php page? guess it could be done but I'd need your help about how to get the categories names from the wikimedia db, is there a protocol or something or I'll just use http and fetch them like the ee.pl?
Having the upload functionality in there would also be a good way to get more people to install the tool. In the long run, it could be enriched with even more client-side functionality such as simple bot tasks.
- ability to save sessions to remember which documents you were working on
- select session upon start
ok I'll postpone those then.
thanx again for all your answers
Pat