On Thu, Nov 4, 2010 at 12:15 AM, Ryan Kaldari rkaldari@wikimedia.org wrote:
As a proponent of agile development, I would actually suggest not worrying about non-Flickr transfers for a first iteration. Most of the non-Flickr cases can be adequately supported by bots and manual uploading in the meantime. If we could get a working Flickr-transfer extension enabled on Commons, that would be a huge step forward and then it could be refactored to support interwiki or generalized file transfer (and to address feedback from the initial version).
While I fully agree that Flickr transfer would be the most useful and has priority, planning more generic functionality in early design (e.g. common function to transfer file from generic URL; abstracted method to determine highest resolution URL from identifier, etc.) would cost very little now but have a huge payoff later. I've seen the "we can refactor this later"-approach blow up too often (in terms of development investment). Yes, even for Java/Eclipse...
To answer your question, the things I like best about the current tools are:
- Automatic license verification
- Being able to use a variety of different URLs and the tool being smart
enough to pull the maximum resolution version regardless
- Automatically pulling descriptions/metadata
It would also be nice to be able to pull an entire set/feed/pool in one go, but that should be for version 2.
Shameless plug: http://toolserver.org/~magnus/flickr_mass.php
Cheers, Magnus