for me, i’m definitely not attached to the project codebase. my main concern is that a tool is in place that achieves the goals thus far achieved, those remaining open, and any future requirements that may arise.
there were reason’s why we didn’t develop the tool externally at first, and reasons why it was developed in the way it was, but looking at the bigger picture, i think erik’s suggestion for developing the tool externally is the most encouraging. i also agree that if the tool is built externally it should not be hosted, in a production state, in labs. with kind regards, dan On Thu, Feb 19, 2015 at 7:26 PM, Brian Wolff <[email protected]> wrote: >>I say "within the context of the current proposal", because I would ask you >>to give serious >>consideration to the following question: Does GLAMWikiToolset need to >>existing within >>MediaWiki? When it was first developed, we didn't have OAuth (so a tool >>outside >> MediaWiki couldn't perform user actions), and our APIs were less mature. >> Today we >> have many examples of external tools that are doing amazing things. > > > > I disagree that OAuth really represents a significant difference in > the landscape. Building it as a bot/separate tool was always an > option. I doubt having the uploader field being some user, vs "glam > upload service" really makes a difference. From what I've seen, > there's even been several instances with gwtoolset where the uploader > is some random user not associated with the museum in question. There > may still be arguments for an external tool, and I know that > originally several people felt it should have been an external tool > (well others disagreed), but I don't think there are any new > arguments. > > As for our apis. With the exception of oAuth, nothing has changed on > that front that's relavent. The last big change to the upload API was > 2012, and for upload by url (which such a tool would likely use, that > hasn't changed much since 2010. > >>I'll be blunt: I will be using the toolset to upload millions of files. >>Taking that into >consideration: what kind of marginal cost are we looking at >>having an external tool >interfacing with the API instead of something built >>directly into the software? These are >media files, not byte-sized edits to >>Wikidata. Also, how is uploading files—even large >numbers of them—not a core >>function of a media repository? > > Marginal cost isn't really different (If one uses the upload by url > api, its doing almost essentially the same thing). If you want to get > marginal cost down further, you'd have to do it like MZMcBride said, > and send in a hard disk. That's quite a bit quicker, but has a higher > cost in preparing the hard disk properly (Needs to have all the > information in a very specific format). Also requires time on the part > of wmf staff to plug the disk in somewhere (I imagine that that works > for one off requests, but would be tiresome if it happened all the > time). Most people who have gone this route have had success (Fae > being the exception, which from what I've read of the situation, was > really beyond WMF's control). > >>Consider also how easy it is for others to contribute to the GWT. GWT >>right now is basically Dan's baby -- and almost necessarily so, >>because the intersection of "know how to write a MediaWiki extension" >>and "can figure out the complex GLAM metadata problems GWT solves for" >>is pretty small. If you can reduce the level of deep MW experience >>required for development, you may have a better chance of the project >>becoming self-sustaining in the long run, with active participation by >>GLAMs in Europeana's network. > > OTOH, typically external tools are also a single person's baby, and > the exposure of being integrated into MW may help with attracting > people. > > However I agree, it would probably be a good idea for the reasons why > gwtoolset wants to be directly integrated to be explicitly enumerated. > > --bawolff > > _______________________________________________ > Glamtools mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/glamtools _______________________________________________ Glamtools mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/glamtools
