On Thu, Nov 4, 2010 at 12:15 AM, Ryan Kaldari <rkaldari(a)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