On 5/4/06, Erik Moeller <eloquence(a)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