On Thu, Nov 4, 2010 at 12:15 AM, Ryan Kaldari <[email protected]> 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 _______________________________________________ Commons-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/commons-l
