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 <bawolff(a)gmail.com> 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
Glamtools(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/glamtools